mirror of
https://github.com/matrix-construct/construct
synced 2024-06-23 04:18:22 +02:00
ircd:Ⓜ️ Formatting/various fixes to README.
This commit is contained in:
Jason Volk
parent
0bd2f896d0
commit
6027a68105
11
README.md
11
README.md
|
|
@ -55,6 +55,9 @@ and have furthered the mission of eliminating the need for external "IRC service
|
|||
*Build dependencies:* **GNU C++ compiler**, **automake**, **autoconf**, **autoconf2.13**,
|
||||
**autoconf-archive**, **libtool**, **shtool**
|
||||
|
||||
*Notes*:
|
||||
- libircd requires a platform capable of loading dynamic shared objects at runtime.
|
||||
|
||||
|
||||
#### Platforms
|
||||
|
||||
|
|
@ -152,8 +155,8 @@ on multiple threads by the embedder's application, libircd will use a single
|
|||
`io_service::strand`.
|
||||
|
||||
This methodology ensures there is an uninterrupted execution working through
|
||||
a single event queue providing service. Even if there are periods of execution
|
||||
which are computationally intense like parsing, hashing, cryptography etc -- this
|
||||
a single event queue providing service. If there are periods of execution
|
||||
which are computationally intense like parsing, hashing, cryptography, etc: this
|
||||
is absorbed in lieu of thread synchronization and bus contention. Scaling this
|
||||
system is done through running multiple instances which synchronize at the
|
||||
application level.
|
||||
|
|
@ -176,9 +179,9 @@ jeopardize the c10k'ness of the daemon the asynchronous pattern is still used.
|
|||
|
||||
##### libircd innovates with formal grammars
|
||||
|
||||
We leverage the boost::spirit system of parsing and printing through formal grammars,
|
||||
We leverage the `boost::spirit` system of parsing and printing through formal grammars,
|
||||
rather than writing our own parsers manually. In addition, we build several tools
|
||||
on top of such formal devices like a type-safe format string library acting as a
|
||||
drop-in for ::sprintf(), but accepting objects like std::string without .c_str()
|
||||
drop-in for `::sprintf()`, but accepting objects like `std::string` without `.c_str()`
|
||||
and prevention of outputting unprintable/unwanted characters that may have been
|
||||
injected into the system somewhere prior.
|
||||
|
|
|
|||
|
|
@ -26,9 +26,24 @@ protocol can be included directly in the `event` object but there are no guarant
|
|||
for if and how a party will pass these keys. To dive right in, here's the list
|
||||
of recognized keys for an `event`:
|
||||
|
||||
|
||||
```
|
||||
auth_events, content, depth, event_id, hashes, membership, origin, origin_server_ts,
|
||||
prev_events, prev_state, room_id, sender, signatures, state_key, type
|
||||
auth_events
|
||||
content
|
||||
depth
|
||||
event_id
|
||||
hashes
|
||||
membership
|
||||
origin
|
||||
origin_server_ts
|
||||
prev_events
|
||||
prev_state
|
||||
room_id
|
||||
sender
|
||||
signatures
|
||||
state_key
|
||||
type
|
||||
|
||||
```
|
||||
|
||||
In the event structure, the value for `sender` and `room_id` and `event_id` are
|
||||
|
|
@ -74,11 +89,21 @@ value of the `state_key` is a user `mxid`.
|
|||
#### Rooms
|
||||
|
||||
The `room` structure encapsulates an instance of the matrix machine. A room
|
||||
consists of a `state` built by a `timeline` of `event` objects. The matrix
|
||||
protocol specifies certain `event` types which are recognized to affect
|
||||
the behavior of the `room`. Here's a list of some of those events:
|
||||
is a container of `event` objects in the form of a timeline. The query
|
||||
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
|
||||
present in the timeline.
|
||||
|
||||
The matrix protocol specifies certain `event` types which are recognized to
|
||||
affect the behavior of the `room`; here is a list of some types:
|
||||
|
||||
|
||||
```
|
||||
m.room.name
|
||||
m.room.create
|
||||
m.room.topic
|
||||
|
|
@ -90,7 +115,8 @@ m.room.power_levels
|
|||
m.room.member
|
||||
m.room.message
|
||||
...
|
||||
`
|
||||
```
|
||||
|
||||
|
||||
Some of these events are `state` events and some are ephemeral. These will be
|
||||
detailed later. All `m.room.*` namespaced events govern the functionality of the
|
||||
|
|
@ -132,8 +158,8 @@ the classic IRC mode change indicating a commitment to change state.*
|
|||
|
||||
References to previous events:
|
||||
|
||||
<code>
|
||||
|
||||
```
|
||||
[A0] <-- [A1] <-- [A2] | A has seen B1 and includes a reference in A2
|
||||
^ |
|
||||
| <---<----<
|
||||
|
|
@ -145,22 +171,21 @@ References to previous events:
|
|||
[T2] : B release B1
|
||||
[T3] A acquire B1 : B release B2
|
||||
[T4] A release A2 :
|
||||
```
|
||||
|
||||
</code>
|
||||
|
||||
Both actors will have their clock (depth) now set to 2 and will issue the
|
||||
next new message at clock cycle 3 referencing all messages from cycle 2 to
|
||||
merge the split in the illustration above which is happening.
|
||||
|
||||
<code>
|
||||
|
||||
```
|
||||
[A0] <-- [A1] <-- [A2] [A4] | A now sees B3, B2, and B1
|
||||
^ | | |
|
||||
| <---<----< ^--<--< <--<
|
||||
| | | |
|
||||
^------- [B1] <-- [B2] <-- [B3] | B now sees A2, A1, and A0
|
||||
|
||||
</code>
|
||||
```
|
||||
|
||||
|
||||
### Implementation
|
||||
|
|
@ -321,8 +346,8 @@ way the federation scales.
|
|||
|
||||
Interference pattern of two IRCd'en:
|
||||
|
||||
<code>
|
||||
|
||||
```
|
||||
::::::::::::::::::::::::::::::::::::
|
||||
--------\:::::::/--\:::::::/--------
|
||||
||||||| |||||||
|
||||
|
|
@ -332,5 +357,4 @@ Interference pattern of two IRCd'en:
|
|||
//|||\\ //|||\\
|
||||
//|// \\|\\//|// \\|\\
|
||||
/|/|/|\|\|\/|/|/|\|\|\|\
|
||||
|
||||
</code>
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in a new issue