We are working on a clean separation/integration of protocol specification from the rest of the content of this site and http://www.psyc.eu/tech.en.html. For a practical way to get started developing, consult the client page, especially since this spec will not treat client-server communications in its first version.
Naming of keywords in the spec is subject to change (see also the big rename). It's a general overhaul of keyword names before finalization of specs. You will be provided a perl script to apply a large number of name changes automatically to your source codes. The intention is to minimize the period of disruption due to keyword name changes, while still choosing the best names and inheritance derivations.
Contents |
PSYC Specification
PSYC is a flexible text-based protocol for delivery of data to a flexible amount of recipients or people, by unicast or multicast. It is primarily used for chat conferencing, presence, pubsub and instant messaging, but not limited to that.
You can browse the specification by chapters below, or pick the printable specification which has it all in one page. It may however not be properly organized yet, and it is missing plenty of important things.
Table of Contents
- Glossary - Definitions of some terms used in the specification.
- Uniform - The definition of uniforms.
- Keyword Naming - The rules for naming methods and variables.
- Methods - A listing of the method families
- Packets - The syntax descriptions of PSYC packets
- Routing variables - A listing of the most important routing variables.
- Entity variables - The listing of entity variables.
- State - Details on State
- Messages - Methods of the _message family.
- Warnings - Methods of the _warn family.
- Errors - Methods of the _error family.
- Failures - Methods of the _fail family.
- Circuits - The specification how things are connected in PSYC.
- Routing - How routing works.
- Context - The definition of contexts and how they work.
- Entities - An overview and definition of what an entity in PSYC is.
- Root Entity - The root entity of a PSYC node.
- Person Entity - The functionality a person entity provides.
- Place Entity - The functionality a place or chat room provides.
Client Protocol
The main specification describes generic inter-entity/interserver protocol. The details on how to link clients to Spec:Person person entities and control them, resulting in a PSYC client protocol, is left to be done later. Some implementations like psyced provide IRC and telnet interfaces directly in the server to circumvent this problem.
We do have a workable client protocol being used by the existing prototype client applications, but it needs to evolve and has no specification. This instead is the work in progress for a PSYC protocol interface to Spec:Person person entities, which may not fit current reality:
- Commands - The command interface for entities
- Client Interface - The main client interface
Development Roadmap
The specification is in development, this is the roadmap/todo list to keep an eye on what should be included in the spec:
Core features that should be defined:
- compact
- parsing packets (DONE: Spec:Packet)
- handling uniforms (DONE: Spec:Uniform)
- circuit establishment (DONE: Spec:Circuit)
- routing roules (DONE: Spec:Routing)
- how does multicast work?
- definition of the functionality of the main entities:
- person (DONE: Spec:Person)
- context (DONE: Spec:Context)
- room/group (IN WORK, SEE: Spec:Place)
- describe the basic set of variables and their data types
- The basic set of method families (IN WORK: Spec:Method)
- basic chat functionality (friends, actions, etc.)
Things that are not directly in the core:
- file transfer
- gateway handling
See also Category:Feature and such.
Specification of What?
The question arose what version of PSYC the spec should contain. Specified should be the things that work, when appropriate. And gaps should be filled with new things. The main aim is, to provide a consistent specification of PSYC. The version number should be applied when the spec is finished.
That means the spec can be incompatible for the moment with psyced and other implementations. However, keep an eye on at least a bit backwards compatibility. Once a consistent state has been reached the implementations should be updated.