rzerres/advotracker
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

advotracker: the backend library

Browse Source 
Signed-off-by: Ralf Zerres <ralf.zerres@networkx.de>
This commit is contained in:
Ralf Zerres
2020-06-12 16:40:58 +02:00
parent f41589263b
commit d93dbd282b
2 changed files with 120 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
lib.rs Normal file
View File

@@ -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")]

42
src/lib.rs Normal file
View File

@@ -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")]