Context
We do have a naming issue concerning all kinds of contexts. Groups could be simple contexts without the elaborate features of places (occasionally also dubbed rooms or chatrooms), but in fact groups as such do not exist. You could have a barebones context, but nobody ever did that. What we do have are presence contexts of a person, which reaches out for the group of friends of that person. Then there are also channels, but they are just a special case of contexts. So whenever you feel oppressed by all of these terms, just think they all basically mean the same thing.
- <lynX> a word of warning here: after becoming aware, that the word group doesn't fit the context of a single person's presence and friendship space i used context as the new word for group, which by consequence means that the old meaning of context must be replaced by another term. channel suits that job very well. in fact all the explanations i had before, that the channel was another context of the group, are no longer needed, because now a channel is another channel of the context. much more logical. by consequence i should update the protocol specification that we shall rename _context into _channel on the protocol level, which is nice to the IRC people, as PSYC will look a little more familiar to them now. ;)
Contents |
Multicast Contexts
PSYC implements multicasting to deliver messages, events and information in general from one to multiple recipients. Contexts provide a semantic model to provide this functionality. Entities usually provide a context, which other entities can subscribe to.
Subscribing to an entity's context means that you want to receive messages and events related to that entity.
Subscribing a context (a multicast sender) whose data interests you is a fundamental
operation.
To protect yourself from SPIM it is necessary, that close to all communications have been created by mutual agreement. Before a sender can multicast information to you, you shall request entry, and it shall grant it to you.
Concepts
- A subscriber (an entity) would like to enter a context to receive its updates.
- A context can either be a person entity who multicasts his presence or a place entity
- Multicast is the one-to-many routing operation of PSYC with optimized distribution, see also Spec:Routing.
Context interface
This section describes the interface of a context. Entities can offer this interface to let other entities subscribe to them.
Subscriber Requesting Entry
The following request methods are the basic set of methods that an entity can use to request becoming part of a context.
_request_context_enter
This requests the membership of a context.
When the request succeeds an _echo_context_enter is sent back to the request as a reply. After the response is sent, the entered entity has (logically) become a member of the context. The person who joined is the _target, obviously.
If the place decides to inform people about new members, it then multicasts a _notice_context_enter to all occupants (including the newly joined entity, as it also informs the joined entity, that others were informed about her arrival). The person who joined is kept in _source_relay in this configuration.
State synchronization MAY be included in the _echo_context_enter reply (for example when the requesting entity asked for a sync, or when the context believes the state needs to be resent). But note that the entering entity is NOT a member at the time of replying to the request. The additional state update MAY be sent in the _notice_context_enter, or as a separate packet (potentially without method).
NOTE: As PSYC nodes know which contexts their entities subscribed, they usually also know when they need to synchronize with the state of a newly entered context. To accomplish this, it is recommended that the PSYC node adds a "?" modifier to the outgoing _request_context_enter, which was initiated by the entity that wants to enter.
_notice_context_enter
You have been joined to the context, which now includes you, and your arrival has been multicast.
This message can only be distinguished from other people joining the channel by looking at the _source_relay routing variable.
_echo_context_enter
The context sends you a unicast acknowledgement, that your _request_context_enter has been positively accepted.
The _source variable contains the address of the context you are a member of now.
When receiving a _echo_context_enter you MUST check whether it is in response to a former request or you trust the context you enter enough. This check is required to prevent others from forcing you into a SPIM context.
Subscriber requesting leave
_request_context_leave
This method asks the context to let you leave it, even though this is formally a polite request, it MUST NOT be denied by the context.
The subscriber MUST NOT disturb his human user with further multicasts from the sender, but it MAY report abuse where appropriate.
_notice_context_leave
When unicast, this method informs the member that she left the context.
When multicast, it informs all members that the sending member has left the context.
NOTE: This method, directed at the context, can also be used to signal an unpolite end of the membership. Unfortunately some IRC gateways require this to properly emulate IRC behaviour. NOTE2: This method does not need a confirmation.
_error & _failure
You may also receive errors or failures stopping the transaction flow, both because there may be a problem or simply because the context doesn't like your face. The _tag_relay included in these messages helps you take appropriate action.
Custom Commands
Custom commands provided by the context (see Create Places for examples) may have collateral effects of entering or leaving channels. This is necessary to implement complex functions like a newscast with a preferences pop-up box. By the choice of preferences the appropriate channels are selected as to maintain optimized multicasting.
Categories: Module | Liquid | Glossary
