The PSYC method, is also nicknamed mc on the API level as in message code or method call. In fact we sometimes wonder if mc is actually more accurate, as the PSYC method goes beyond the regular object-oriented or remote procedure call notion of a method.
In Method Naming we discuss how we can improve the method names and their inheritance capabilities now that we have gained experience with them. See also the protocol specifications on Keyword Naming and all that.
We use the word family to mean the top level word in the method name hierarchy.
In fact the word family also applies to the top-level names of variables.
Contents |
Method Families
PSYC packets usually have a method, which adhere to keyword naming. A method has to belong to one of the following method families. Each family comes with a default semantic and behavior. Follow the links for documentation of each family.
It is impossible to support all existing methods, because in PSYC it is legal to add custom extensions, derived by inheritance. An application MUST be able to handle all standard method families, and it MUST be able to handle any unknown method by applying inheritance in order to find a known method it is derived from. It MUST also be able to display any text message it carries using the psyctext template rendering, when appropriate.
All packets with a method that belongs to the _request family SHOULD have a _tag attached (see also Spec:Routing-Variables about Tagging).
NOTE: See also _request_context_enter.
Messages and Requests
Information reporting
Failure reports
Data interchange
- _data
Rationale 0.99
These are the current method families and a table of their properties:
TEMPLATE REPLY VISIBLE LOGGABLE MANUAL _data - - - - - _message - - x x x _message_echo - x x+- x x _request x - +- + ? _notice x - x+ + - _list x x x - - _echo x x +- - - _status x x + -+ - _info x x + -+ - _warning x x + + - _error x x + + - _failure x x + + -
TEMPLATE: carry a psyctext template in their body.
REPLY: should be issued in reply to something, thus reflecting whatever tag. Also you SHOULD not generate a reply to a reply.
VISIBLE: client recommendations on how the method should be displayed to the end user. '+' means just temporarily, as in a status output line or window. 'x' means long-term, using a scrollable chat view. '-' means to suppress the message from view. multiple options may be appropriate according to the situation or needs of the user.
LOGGABLE: should be archived as new message for the recipient to see when she comes online. loggable is independent from visible: should a message be deemed not to be shown but logged instead, the user can later consult the lastlog to find detailed information on what happened. Echos for example should always be logged and displayed when inspecting the log, no matter what the setting for real-time echo display is.
MANUAL: should never be automatically generated. these messages should always reflect actual human typing/talking activity.