Walk-through — How EFB works¶
EH Forwarder Bot is an extensible framework that allows user to control and manage accounts from different chat platforms in a unified interface. It consists of 4 parts: a Master Channel, some Slave Channels, some Middlewares and a Coordinator.
- master channel
The channel that directly interact with the User. It is guaranteed to have one and only one master channel in an EFB session.
- slave channel
The channel that delivers messages to and from their relative platform. There is at lease one slave channel in an EFB session.
Component of the framework that maintains the instances of channels, and delivers messages between channels.
Module that processes messages and statuses delivered between channels, and make modifications where needed.
Concepts to know¶
A common term that refers to both channels and middlewares.
- the User
- the User Themself
This term 1 can refer to the user of the current instance of EH Forwarder Bot, operating the master channel, and the account of an IM platform logged in by a slave channel.
- private chat
A conversation with a single person on the IM platform. Messages from a private conversation shall only has an author of the User Themself, the other person, or a “system member”.
For platforms that support bot or something similar, they would also be considered as a “user”, unless messages in such chat can be sent from any user other than the bot.
For chats that the User receive messages, but cannot send message to, it should also be considered as a private chat, only to raise an exception when messages was trying to send to the chat.
- group chat
A chat that involves more than two members. A group chat MUST provide a list of members that is involved in the conversation.
- system chat
A chat that is a part of the system. Usually used for chats that are either a part of the IM platform, the slave channel, or a middleware. Slave channels can use this chat type to send system message and notifications to the master channel.
- chat member
Messages are delivered strictly between the master channel and a slave channel. It usually carries an information of a certain type.
Each message should at least have a unique ID that is distinct within the slave channel related to it. Any edited message should be able to be identified with the same unique ID.
Information that is not formatted into a message. Usually includes updates of chats and members of chats, and removal of messages.
The job of slave channels is relatively simple.
Deliver messages to and from the master channel.
Maintains a list of all available chats, and group members.
Monitors changes of chats and notify the master channel.
Features that does not fit into the standard EFB Slave Channel model can be offered as Additional features.
Master channels is relatively more complicated and also more flexible. As it directly faces the User, its user interface should be user-friendly, or at least friendly to the targeted users.
The job of the master channel includes:
Receive, process and display messages from slave channels.
Display a full list of chats from all slave channels.
Offer an interface for the User to use “extra functions” from slave channels.
Process updates from slave channels.
Provide a user-friendly interface as far as possible.
Middlewares can monitor and make changes to or nullify messages and statuses delivered between channels. Middlewares are executed in order of registration, one after another. A middleware will always receive the messages processed by the preceding middleware if available. Once a middleware nullify a message or status, the message will not be processed and delivered any further.
“Themself” here is used as a derived form of a gender-neutral singular third-person pronoun.