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

delete me!

Browse Source 
Signed-off-by: Ralf Zerres <ralf.zerres@networkx.de>
This commit is contained in:
Ralf Zerres
2020-06-19 17:46:19 +02:00
parent 410bdfb537
commit a4b2028cb1
1 changed files with 0 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
lib.rs
View File

@@ -1,78 +0,0 @@
//! # 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")]