79 lines
3.5 KiB
XML
79 lines
3.5 KiB
XML
//! # 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
|
|
//!
|
|
//! 
|
|
//!
|
|
//! ## Workflow visualization
|
|
//!
|
|
//! The following image try to illustrate the major components and its workflow.
|
|
//!
|
|
//! 
|
|
//!
|
|
|
|
//#![feature(extern_doc)]
|
|
//#[doc(include="../README.md")]
|