mirror of https://gitlab.com/litecord/litecord.git
docs: add docs/pubsub.md, revamp README
This commit is contained in:
parent
982ac6f05b
commit
a9be2a7cce
|
|
@ -1,3 +1,5 @@
|
||||||
# Internal documentation
|
# Internal documentation
|
||||||
|
|
||||||
The Litecord Voice Server Protocol (LVSP) is documented here.
|
- `admin_api.md` for Litecord's Admin API.
|
||||||
|
- `lvsp.md` for the Litecord Voice Server Protocol.
|
||||||
|
- `pubsub.md` for how Pub/Sub works in Litecord.
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,57 @@
|
||||||
|
# Pub/Sub (Publish/Subscribe)
|
||||||
|
|
||||||
|
Please look over wikipedia or other sources to understand what it is.
|
||||||
|
This only documents how an events are generated and dispatched to clients.
|
||||||
|
|
||||||
|
## Event definition
|
||||||
|
|
||||||
|
Events are composed of two things:
|
||||||
|
- Event type
|
||||||
|
- Event payload
|
||||||
|
|
||||||
|
More information on how events are structured are in the Discord Gateway
|
||||||
|
API documentation.
|
||||||
|
|
||||||
|
## `StateManager` (litecord.gateway.state\_manager)
|
||||||
|
|
||||||
|
StateManager stores all available instances of `GatewayState` that identified.
|
||||||
|
Specific information is over the class' docstring, but we at least define
|
||||||
|
what it does here for the next class:
|
||||||
|
|
||||||
|
## `EventDispatcher` (litecord.dispatcher)
|
||||||
|
|
||||||
|
EventDispatcher declares the main interface between clients and the side-effects
|
||||||
|
(events) from topics they can subscribe to.
|
||||||
|
|
||||||
|
The topic / channel in EventDispatcher can be a User, or a Guild, or a Channel,
|
||||||
|
etc. Users subscribe to the channels they have access to manually, and get
|
||||||
|
unsubscribed when they e.g leave the guild the channel is on, etc.
|
||||||
|
|
||||||
|
Channels are identified by their backend and a given key uniquely identifying
|
||||||
|
the channel. The backend can be `guild`, `member`, `channel`, `user`,
|
||||||
|
`friend`, and `lazy_guild`. Backends *can* store the list of subscribers, but
|
||||||
|
that is not required.
|
||||||
|
|
||||||
|
Each backend has specific logic around dispatching a single event towards
|
||||||
|
all the subscribers of the given key. For example, the `guild` backend only
|
||||||
|
dispatches events to shards that are properly subscribed to the guild,
|
||||||
|
instead of all shards. The `user` backend just dispatches the event to
|
||||||
|
all available shards in `StateManager`, etc.
|
||||||
|
|
||||||
|
EventDispatcher also implements common logic, such as `dispatch_many` to
|
||||||
|
dispatch a single event to multpiple keys in a single backend. This is useful
|
||||||
|
e.g a user is updated and you want to dispatch `USER_UPDATE` events to many
|
||||||
|
guilds without having to write a loop yourself.
|
||||||
|
|
||||||
|
## Backend superclasses (litecord.pubsub.dispatcher)
|
||||||
|
|
||||||
|
The backend superclasses define what methods backends must provide to be
|
||||||
|
fully functional within EventDispatcher. They define e.g what is the type
|
||||||
|
of the keys, and have some specific backend helper methods, such as
|
||||||
|
`_dispatch_states` to dispatch an event to a list of states without
|
||||||
|
worrying about errors or writing the loop.
|
||||||
|
|
||||||
|
The other available superclass is `DispatchWithState` for backends that
|
||||||
|
require a list of subscribers to not repeat code. The only required method
|
||||||
|
to be implemented is `dispatch()` and you can see how that works out
|
||||||
|
on the backends that inherit from this class.
|
||||||
Loading…
Reference in New Issue