//! # nctalkbot-framework
//!
//! `nctalkbot` is a rust implemented framework, that describes a client/server infrastructure
//! needed to build a scalable chatbot that communicates with Nextcloud.
//!
//! ## Overview
//!
//! The framework will offer the following components:
//!
//! * Server side
//!
//!   `nctalkproxyd` implements the server component. This proxy handles all
//!   the interaction with the Nextcloud API. It will monitor NextCloud Talk
//!   rooms while listening for new chat requests.
//!   Incoming requests are processed appropriately and session relevant data
//!   are exchanged via gRPC message between the proxy and the client side.
//!   All interaction between the proxy and the Nextcloud server are encapsulated
//!   inside http2 messages.
//!   To keep track of the addressed rooms and its participants, it will take
//!   advantage of an [`in memory database`](https://github.com/mambisi/escanor).
//!   Communication is handled using the redis protocol.
//!   New chat responses are advertised to the user as rendered chat messages
//!   inside its originating room.
//!
//! * Client side
//!
//!   In order to create a functional chatbot, a client counterpart has to be
//!   implemented as well. Your client will interact with `nctalkproxyd` while
//!   sending and recieving gRPC messages.
//!   You may implemnt it in any supported native languages that support gRPC
//!   bindings.
//!
//!   `nctalkbot-jitsi` is reference implementation, that take advantage of the
//!   framework to create new jitsi meetings.
//!   The actual meeting is created in a new window of a supported browser session.
//!   If a new gRPC meeting request is received, the client will process the
//!   required steps following the [JitsiMeetExternal API](https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md).
//!   The framework is taking care to preset the session parameters (eg. Name,
//!   password), beside participant specicfic options (participant name,
//!   language, etc).
//!
//! ## gRPC Overview
//!
//! Like many RPC systems, gRPC is based around the idea of defining a service,
//! specifying the methods that can be called remotely with their parameters and
//! return types. By default, gRPC uses protocol buffers as the
//! Interface Definition Language (IDL) for describing both the service interface
//! and the structure of the payload messages. It is possible to use other
//! alternatives if desired.
//!
//! gRPC lets you define four kinds of service method:
//!
//! * Unary RPCs
//!   The client sends a single request to the server and gets a single response back
//! * Server streaming RPCs
//!   The client sends a request to the server and gets a stream to read a sequence of messages back.
//! * Client streaming RPCs
//!   The client writes a sequence of messages and sends them to the server,
//!   again using a provided stream. Once the client has finished writing the messages,
//!   it waits for the server to read them and return its response.
//! * Bidirectional streaming RPCs#
//!   Both sides send a sequence of messages using a read-write stream.
//!   The two streams operate independently, so clients and servers can read and write
//!   in whatever order they like
//!
//! Have a look at the following bird's eye illustration of the processes
//!
//! ![gRPC-schema.png](../images/gRPC-schema.png)
//!
//! ## Workflow visualization
//!
//! The following image try to illustrate the major components and its workflow.
//!
//! ![nctalkbot-framework.png](../images/nctalkbot-framework.png)
//!

//#![feature(extern_doc)]
//#[doc(include="../README.md")]