use std::collections::HashMap;
use std::sync::RwLock;
pub struct Message {
    pub kind: String,
    pub json: String,
}
pub type Implementation = fn(&Message) -> ();
struct MessageHandler {
    implementation: Implementation,
    message: Message,
}
impl MessageHandler {
    pub fn new(implementation: Implementation, message: Message) -> Self {
        Self {
            implementation,
            message,
        }
    }
    pub fn handle(&self) {
        let _ = &(self.implementation)(&self.message);
    }
}
pub struct Mediator {
    storage: RwLock<HashMap<String, Vec<Implementation>>>,
}
impl Mediator {
    pub fn new() -> Self {
        let data = HashMap::with_capacity(100);
        let storage = RwLock::new(data);
        Self { storage }
    }
    pub fn add(&mut self, kind: String, handler: Implementation) {
        let key = kind.clone();
        let mut backing = self.storage.write().unwrap();
        let target = &mut *backing;
        if target.contains_key(&key) {
            let handlers = target.get_mut(&key).unwrap();
            handlers.push(handler);
        } else {
            let mut handlers: Vec<Implementation> = Vec::new();
            handlers.push(handler);
            target.insert(key, handlers);
        }
    }
    pub fn invoke(&self, msg: &Message) {
        let kind = msg.kind.clone();
        let json = msg.json.clone();
        let backing = self.storage.read().unwrap();
        let target = &*backing;
        if !target.contains_key(&msg.kind) {
            return;
        }
        let handlers = target.get(&msg.kind).unwrap();
        for handler in handlers {
            let c_kind = kind.clone();
            let c_json = json.clone();
            let c_handler = (*handler).clone();
            tokio::spawn(async move {
                let wrapper = MessageHandler::new(
                    c_handler,
                    Message {
                        kind: c_kind,
                        json: c_json,
                    },
                );
                wrapper.handle();
            });
        }
    }
}

// Adapted from: https://github.com/tokio-rs/mini-redis/blob/069a8e5ee0de445ad3e642548d196ef6b4fa8bc1/src/shutdown.rs
use tokio::sync::broadcast;
pub struct Shutdown {
    /// The receive half of the channel used to listen for shutdown.
    notify: broadcast::Receiver<i32>,
}
impl Shutdown {
    /// Create a new `Shutdown` backed by the given `broadcast::Receiver`.
    pub fn new(notify: broadcast::Receiver<i32>) -> Self {
        Self { notify }
    }
    #[allow(dead_code)]
    pub fn replicate(&self) -> Self {
        Self {
            notify: self.notify.resubscribe(),
        }
    }
    /// Receive the shutdown notice, waiting if necessary.
    pub async fn recv(&mut self) {
        // Cannot receive a "lag error" as only one value is ever sent.
        let _ = self.notify.recv().await;
    }
}

use tokio::time::{sleep, Duration};
pub struct Service {}
pub struct ServiceError {}
impl Service {
    pub fn new() -> Self {
        Self {}
    }
    pub async fn wait(&self) -> Result<u64, ServiceError> {
        sleep(Duration::from_secs(7)).await;
        Result::Ok(117)
    }
    pub async fn serve(&self, _handle: u64) -> Result<(), ServiceError> {
        sleep(Duration::from_secs(15)).await;
        Result::Ok(())
    }
}

use crate::mediator::{Mediator, Message};

use crate::service::Service;
use crate::shutdown::Shutdown;
use log::error;

static SERVE_DEFAULT: bool = true;

    mediator: Mediator,

    control: Shutdown,

    pub fn new() -> Self {
        info!("BOOT: Started");
        let mut mediator = Mediator::new();

    pub fn new(control: Shutdown) -> Self {
        info!("BOOT: START");
        // Bootstrap the components.
        info!("BOOT: READY");
        Self { control }
    }
    pub async fn run(&mut self) {
        info!("SERVER: RUN");
        let service_loop = tokio::spawn(async move {
            info!("SERVICE: RUN");
            while SERVE_DEFAULT {
                let round = Service::new();
                let service_handle = round.wait().await;
                match service_handle {
                    Ok(handle) => {
                        tokio::spawn(async move {
                            info!("SERVICE: PROCESSING (REASON: Acquired handle {}).",handle);
                            let service_response = round.serve(handle).await;
                            match service_response {
                                Ok(_) => info!("SERVICE: PROCESSED (REASON: Handle {} has been processed.)",handle),
                                Err(_service_error) => error!("SERVICE: FAILURE (REASON: Request handling error for handle {}.)",handle)
                            }
                        });
                    }
                    Err(_service_error) => error!("SERVICE: FAILURE (REASON: Unable to acquire new handle for request servicing.)")
                }
            }
        });

        // Bootstrap the components to the mediator.

        self.control.recv().await;

        info!("BOOT: Ready");

        info!("SERVER: RECEIVED CONTROL SIGNAL");

        Self { mediator }
    }

        service_loop.abort();

    pub fn run(&mut self) {
        info!("SERVER: Running");
        loop {
            // Use the tokio framework here to run the server loop
            // which handles incoming network requests.
        }

        info!("SERVICE: CANCELLED");
        info!("SERVER: STOP");

use crate::shutdown::Shutdown;

use std::process::exit;
use tokio::signal;
use tokio::sync::broadcast;

mod mediator;

mod service;
mod shutdown;

    let _handle = log4rs::init_file("log4rs.config.yml", Default::default()).unwrap();

    log4rs::init_file("log4rs.config.yml", Default::default()).unwrap();
    let version = env!("CARGO_PKG_VERSION");
    info!("MAIN: v{}", version);
    info!("MAIN: START");

    info!("MAIN: INIT STARTED");
    info!("MAIN: v0.1.0");

    let (shutdown_tx, shutdown_rx) = broadcast::channel(256);

        let mut server = Server::new();

        let control = Shutdown::new(shutdown_rx);
        let mut server = Server::new(control);

        server.run();

        server.run().await;

    match signal::ctrl_c().await {
        Ok(()) =>
        // Once we receive the signal here we need
        // to be sure that we exit the application
        // as e.g. CTRL-C is no longer processed if
        // pressed again.
        {
            info!("MAIN: STOP SIGNAL RECEIVED");
            // SIGTERM is 15
            let received = 15;
            shutdown_tx.send(received).unwrap();
            info!("MAIN: SEND CONTROL SIGNAL");
        }
        Err(err) => {
            error!("MAIN: Unable to listen for shutdown signal: {}", err);
            // we also shut down in case of error
            panic!("MAIN: Abnormal shutdown.");
        }
    }

    info!("MAIN: WAITING FOR EXIT");

        Ok(_) => {}
        Err(server_fault) => error!("SERVER: RUNTIME ERROR = {}", server_fault),

        Ok(_) => {
            info!("MAIN: EXIT SUCCESS");
            exit(0);
        }
        Err(server_fault) => error!("MAIN: RUNTIME ERROR = {}", server_fault),

refresh_rate: 30 seconds
appenders:
  stdout:
    kind: console
root:
  level: trace
  appenders:
    - stdout

refresh_rate: 30 seconds
appenders:
  stdout:
    kind: console
root:
  level: trace
  appenders:
    - stdout

# Concepts
This chapter describes the core concepts around the implementation and the IRC specification. Some material may be restated from the source but it is gathered here for reference purposes.
## IRC
For the core IRC concepts see: [IRC concepts](https://modern.ircdocs.horse/#irc-concepts)
## Implementation
### Client
This is something that sends bytes to our server according to the IRC protocol (something that communicates with the server but is not a server). This is also something outside of this implementation and this is modelled as something from which we receive and send bytes to.
### Server
This is our implementation which communicates with the client and other servers in the same network. According to IRC specification network consists of servers and even though there is server to server protocols available in practise one network consists of same server implementations and they can use any protocol they wish to communicate state changes between them. We will utilize this in our implementation.
### User
This entity models a real user (either human or bot) which uses the client to communicate with our server.
### Channel
Channels represent the logical conversation groups in an IRC network. These are synced between servers in the network. This entity ties users to channels in which they can exchange messages.
### Capability
When the client connects to the server they first have an exchange of information which tells the client what capabilities the server provides. This allows the client to establish reasonable communication with the server. In the implementation different capabilities are implemented in a modular manner which are queried during runtime to provide the capability information to the client.
# Architecture
In general principle we follow modular monolith approach where we have a single executable for the application but that application is composed of modules which are independent and focus on specific features (capabilities) and the runtime then ties these together. In addition there are modules which handles the low-level work of communication. Different components communicate with each other using the mediator pattern (this allows loose coupling between components but it is not the most high-performant way of running the IRC server).
## Components
### Server
This is the main high-level component that drives our server instance.
#### Capability
There are multiple capability components that each implement a specific functionality to the server.
### Pool
This is the component which tracks the running service instance in the network it is attached to. Network can consist of single server instance. State changes in this instance are then propagated to other servers in pool.
#### Server Communicator
This sub-component of the pool manages the communication between server instances.
### State Manager
This component maintains the state information (users, channels, etc.) for the current instance. It is linked to the pool component and the pool observes the changes in the state manager and propagates them forward and vice versa. That is pool may receive state update from a different server instance and pool then signals these changes to this instance's state manager.
### Protocol Stack
This component maintains the reference information for different communication and message components about specific IRC code constants and other similar information in the IRC protocol.
### Communicator
This component is responsible for sending and receiving bytes between client and server. It ensures the correct formatting of messages and their validation. This component is also linked to the state manager.
### Mediator
This is the infrastructure component that ties other components together. Components can register with the mediator to receive certain type of messages. These abstract messages are defined outside the components to avoid dependencies between components. This is the most general purpose of the modules defined and in principle will work with other applications as well.

# Concepts
This chapter describes the core concepts around the implementation and the IRC specification. Some material may be restated from the source but it is gathered here for reference purposes.
## IRC
For the core IRC concepts see: [IRC concepts](https://modern.ircdocs.horse/#irc-concepts)
## Implementation
### Client
This is something that sends bytes to our server according to the IRC protocol (something that communicates with the server but is not a server). This is also something outside of this implementation and this is modelled as something from which we receive and send bytes to.
### Server
This is our implementation which communicates with the client and other servers in the same network. According to IRC specification network consists of servers and even though there is server to server protocols available in practise one network consists of same server implementations and they can use any protocol they wish to communicate state changes between them. We will utilize this in our implementation.
### User
This entity models a real user (either human or bot) which uses the client to communicate with our server.
### Channel
Channels represent the logical conversation groups in an IRC network. These are synced between servers in the network. This entity ties users to channels in which they can exchange messages.
### Capability
When the client connects to the server they first have an exchange of information which tells the client what capabilities the server provides. This allows the client to establish reasonable communication with the server. In the implementation different capabilities are implemented in a modular manner which are queried during runtime to provide the capability information to the client.
# Architecture
In general principle we follow modular monolith approach where we have a single executable for the application but that application is composed of modules which are independent and focus on specific features (capabilities) and the runtime then ties these together. In addition there are modules which handles the low-level work of communication.
## Components
### Server
This is the main high-level component that drives our server instance.
#### Capability
There are multiple capability components that each implement a specific functionality to the server.
### Pool
This is the component which tracks the running service instance in the network it is attached to. Network can consist of single server instance. State changes in this instance are then propagated to other servers in pool.
#### Server Communicator
This sub-component of the pool manages the communication between server instances.
### State Manager
This component maintains the state information (users, channels, etc.) for the current instance. It is linked to the pool component and the pool observes the changes in the state manager and propagates them forward and vice versa. That is pool may receive state update from a different server instance and pool then signals these changes to this instance's state manager.
### Protocol Stack
This component maintains the reference information for different communication and message components about specific IRC code constants and other similar information in the IRC protocol.
### Communicator
This component is responsible for sending and receiving bytes between client and server. It ensures the correct formatting of messages and their validation. This component is also linked to the state manager.

version = "0.1.0"

version = "0.2.0"

version = "0.1.0"

version = "0.2.0"