MirrorHub/construct
0
0
Fork 0
mirror of https://github.com/matrix-construct/construct synced 2024-11-26 00:32:35 +01:00
Code Issues Releases Wiki Activity

ircd:Ⓜ️ Update README.

Browse source
This commit is contained in:
Jason Volk 2017-12-12 13:06:28 -07:00
parent 072137bd35
commit 49b32de864
1 changed files with 29 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
include/ircd/m/README.md
View file

@ -95,8 +95,8 @@ complexity for information in a room timeline is as follows:
- Message (non-state) events in the timeline have a linear lookup time:
the timeline must be iterated in sequence to find a satisfying message.
- State events in the timeline have logarithmic lookup: the implementation
is expected to maintain a map of the `state_key` values for state events
- State events in the timeline have a logarithmic lookup: the implementation
is expected to maintain a map of the `type`,`state_key` values for events
present in the timeline.
The matrix protocol specifies certain `event` types which are recognized to
@ -190,6 +190,33 @@ merge the split in the illustration above which is happening.
### Implementation
#### Model
This system embraces the fact that "everything is an event." It then follows
that everything is a room. We use rooms for both communication and storage of
everything.
There is only one† backend database and it stores events. For example: there
is no "user accounts database" holding all of the user data for the server-
instead there is an `!accounts` *room*. To use these rooms as efficient
databases we categorize a piece of data with an event `type` and key it with
the event `state_key` and the value is the event `content`. Iteration of these
events is also possible. This is now a sufficient key-value store as good as
any other approach; better though, since such a databasing room retains all
features and distributed capabilities of any other room. We then focus our
efforts to optimize the behavior of a room, to the benefit of all rooms, and
all things.
† Under special circumstances other databases may exist but they are purely
slave to the events database: i.e one could `rm -rf` a slave database and it
would be rebuilt from the events database. These databases only exist if an
event is *truly* inappropriate and doesn't fit the model even by a stretch.
An example of this is the search-terms database which specializes in indexing
individual words to the events where they are found so content searches can be
efficient.
#### Flow
This is a single-writer/multiple-reader approach. The "core" is the only writer.
The write itself is just the saving of an event. This serves as a transaction
advancing the state of the machine with effects visible to all future