10 lines
1.2 KiB
Plaintext
10 lines
1.2 KiB
Plaintext
|
Bot core receives stream of events; steps through them in turn
|
||
|
|
Bot has lots of model objects, each one registers itself with a type identifier (eg. m.room.message), corresponding to event types.
|
||
|
|
Bot core simply palms the event to all handlers of the relevant kind. They can then return a "processed event". Bot core will add that to the event queue.
|
||
|
|
Separate loop of the bot will pull events out of the queue and fire them. By default they'll do nothing, the outer layer can register handlers (and request a list of handlers, to make it easier to manage removing).
|
||
|
|
Can also add filters/splitters, a special kind of handler that will return new events to be fired; can be used for making up internal event types, eg. a splitter that looks at the first word in the message and fires an event of that type, to make a command handler.
|
||
|
|
The whole bot will be synchronous. However, all network/disk/DB/etc., basically all external, will just create a task and push it into a separate work queue which will fire off at maximum possible rate. Try to avoid making get calls.
|
||
|
|
Raw events will not be exposed, only processed events. This is not a "you have full control" framework. This is a clean, unified, easy-to-use framework.
|
||
|
|
|
||
|
|
https://spec.matrix.org
|
||
|
|
https://www.matrix.org/docs/develop/
|