//! Jupiter is a library for providing high throughput ultra low latency services via the RESP
//! protocol as defined by Redis.
//!
//! # Introduction
//! **Jupiter** is a framework for wrapping **compute** or **memory intense** components to
//! provide them as **high throughput** and **ultra low latency** services to
//! applications built on managed runtimes like **node.js**, **Java**, **Ruby**.
//!
//! These managed runtimes are great for building sophisticated web applications but have limited
//! capabilities when raw compute power or optimized memory utilization is required. This
//! on the other hand is an area where **Rust** shines, as it permits to write low-level
//! and highly optimized code which is still safe to run.
//!
//! Therefore all we need is a simple an efficient way of combining the best of both worlds.
//! To minimize the overhead of communication, we use the [RESP Protocol](https://redis.io/topics/protocol)
//! as defined by **Redis**. In contrast to HTTP this is way simpler to parse and handle while
//! also supporting zero-copy operations. Another benefit is, that for nearly every platform
//! there is already a Redis/RESP client available.
//!
//! # SIRIUS / Java
//! We at [scireum](https://www.scireum.de) use **Jupiter** in conjunction with our open source
//! Java framework [SIRIUS](https://github.com/scireum/sirius-kernel) to build web based
//! applications.
//!
//! We use **Jupiter** as an LRU cache for intermediate search results and search metadata. We also
//! store large parts of semi-constant masterdata (think of "all ZIP codes and street names in
//! germany) there. Both of these frameworks are contributed to the open source community and can
//! be either used in own applications or directly by running a
//! [Jupiter IO](https://hub.docker.com/repository/docker/scireum/jupiter-io) instance.
//!
//! Our most central use of this framework lies in **Quasar** which sadly has to remain closed
//! source. This application contains our complete text processing framework which runs everything
//! from syntactical pre-processing to full morphological analysis steps in order to maintain our
//! excellent search experience in our products.
//!
//! # Features
//! * **Ultra fast non allocating parser for RESP queries** (as sent by redis-cli and redis clients).
//! The built-in server will use a single buffer per connection to read, parse and process queries.
//! To deliver a response, a single buffer is allocated to buffer the response to minimize the
//! number of required sys-calls to write a response on the wire.
//! * **100% Async/Await** - the whole server builds upon [tokio](https://tokio.rs/) and async/await
//! primitives as provided by Rust. Also, all commands handlers are build as actors to simplify
//! concurrency correctness and to also minimize any synchronization overheads.
//! * **Reload-aware config facility** which permits to update the configuration during operation.
//! Therefore no restart is ever required, even when changing the IP binding or port. This is kind
//! of important for a in-memory application which might have an expensive startup time.
//! * **Build in management commands**. The *core* module provides a set of management commands to monitor
//! and inspect the state of the system.
//! * **Simple and well documented code base**. After all, Jupiter isn't a large framework at all. This permits
//! every user to browse and understand its source code and when to expect from the system. Also this is due to
//! the fact that Jupiter stands on the shoulders of giants (especially [tokio](https://tokio.rs/)).
//!
//! # Examples
//! A complete example of using Jupiter can be found here:
//! [Jupiter IO](https://github.com/scireum/jupiter/tree/master/jupiter-io).
//!
//! Still a short example on how to initialize the library can be found here [Builder](builder::Builder).
//! A super simple command can be found in the implementation of [ping](ping::install). A more
//! sophisticated example would be [core](core).
//!
//! # Using Jupiter
//! **Jupiter** is intended to be used as a framework for your custom application. However the
//! example instance [Jupiter IO](https://github.com/scireum/jupiter/tree/master/jupiter-io) which
//! features an **LRU cache** and an **InfoDB** instance can also be directly used via docker:
//! [Docker image](https://hub.docker.com/repository/docker/scireum/jupiter-io).
//!
//! Further infos can be found on [crates.io/crates/jupiter](https://crates.io/crates/jupiter)
use simplelog::{ConfigBuilder, LevelFilter, SimpleLogger};

pub mod average;
pub mod builder;
pub mod commands;
pub mod config;
pub mod core;
pub mod flag;
pub mod fmt;
pub mod infograph;
pub mod lru;
pub mod ops;
pub mod ping;
pub mod platform;
pub mod repository;
pub mod request;
pub mod response;
pub mod server;
pub mod signals;

/// Contains the version of the Jupiter library.
pub const JUPITER_VERSION: &'static str = "DEVELOPMENT-SNAPSHOT";

/// Contains the git commit hash of the Jupiter build being used.
pub const JUPITER_REVISION: &'static str = "NO-REVISION";

/// Initializes the logging system.
///
/// Note that most probably the simples way is to use a [Builder](builder::Builder) to setup the
/// framework, which will also setup logging if enabled.
pub fn init_logging() {
    static DATE_FORMAT: &str = "[%Y-%m-%dT%H:%M:%S%.3f]";
    if let Err(error) = SimpleLogger::init(
        LevelFilter::Debug,
        ConfigBuilder::new()
            .set_time_format_str(DATE_FORMAT)
            .set_thread_level(LevelFilter::Trace)
            .set_target_level(LevelFilter::Error)
            .set_location_level(LevelFilter::Trace)
            .build(),
    ) {
        panic!("Failed to initialize logging system: {}", error);
    }
}