13 lines
1.6 KiB
Plaintext
13 lines
1.6 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/
|
|
|
|
Main chat lib defines API - is NOT a class, the module itself is a singleton
|
|
Specific proto libs are classes, instansiate with the module + account info, it'll hook itself into the module. For convenience, if the module isn't provided they'll do it themselves, and provide a .run() wrapper. If that's used with a provided module (set a flag), they emit a warning. |