From d93dbd282b53366e1f5f66a1c1d2f09136ca9139 Mon Sep 17 00:00:00 2001 From: Ralf Zerres Date: Fri, 12 Jun 2020 16:40:58 +0200 Subject: [PATCH] advotracker: the backend library Signed-off-by: Ralf Zerres --- lib.rs | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/lib.rs | 42 +++++++++++++++++++++++++++++ 2 files changed, 120 insertions(+) create mode 100644 lib.rs create mode 100644 src/lib.rs diff --git a/lib.rs b/lib.rs new file mode 100644 index 0000000..f584e03 --- /dev/null +++ b/lib.rs @@ -0,0 +1,78 @@ +//! # 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")] diff --git a/src/lib.rs b/src/lib.rs new file mode 100644 index 0000000..ca49149 --- /dev/null +++ b/src/lib.rs @@ -0,0 +1,42 @@ +//! # advotracker-framework +//! +//! `AdvoTracker` is a framework implemented in the `Rust` language +//! (![Rust.svg](../images/rust-logo-blk.svg)). +//! It assembles a client/server infrastructure needed to build a scalable, robust +//! tool used to keep track of legal mandate data within an online advice. +//! +//! ## Overview +//! +//! The framework will offer the following components: +//! +//! * Server side +//! +//! `advotrackerd` implements the server component. For example, it will handle all +//! the interaction with an underling database engine. +//! +//! * Client side +//! +//! `advotracker` is the client counterpart that represents the frontend. +//! To offer a operating system agnostic graphical interface, it will take advantage +//! of `OrbTk`, a Rust naitive GUI framework (![OrbTk.svg](../images/orbtk-logo.svg)). +//! +//! This component is the entry point for all `AdvoTracker` users. +//! All offered tasks are organized in roles. Thus, a user needs to authenticate agains +//! the system to make use of and access its assigned roles. +//! +//! The followin list is an +//! - enter and capture legal mandate date wile working in an online advice +//! - search inside the legal advices database +//! - export legal advices +//! - follow the history of legal advices +//! - get statistics about completed advices +//! +//! ## Workflow visualization +//! +//! The following image try to illustrate the major components and its workflow. +//! +//! ![advotracker-framework.png](../images/advotracker-framework.png) +//! + +//#![feature(extern_doc)] +//#[doc(include="../README.md")]