/n/remote/name
/n/remote/n
/n/remote/n/ctl
Spree serves a name-space consisting of a directory for each clique that is currently active, and a file, name, that holds the authenticated name of the user that has mounted the spree namespace. A clique's directory holds at least one file, ctl; if a client opens this file, it can write to it communicate with the clique's engine, and read from it to find updates to the state of the clique. Messages written to the file are formed as text and the write yields an error if there is an error executing the command. The first message written to the file is the initial request to join the clique; conventionally it is the string join, but some engines accept other kinds of message (e.g. watch). If the initial request succeeds, the client will be informed of the current state of the clique by means of update messages read from the same file. Reading from the file will block until an update is available, whereupon the read request will return as many updates are available, separated by newline characters. If there are more updates available than can fit in the read request, the last two bytes of the buffer read will be a newline character and an asterisk (*) respectively, indicating that there are more updates to come.
When spree is first started, it creates one clique, a ``lobby'' (see spree-lobby(4)) that allows other cliques to be created; this is named 0).
A client cannot join a particular clique more than once.
A zero-length write to the ctl file causes any reads of that file from the same file descriptor to yield EOF (no bytes). This is necessary to force a hangup under systems such as Windows, where it is not possible to interrupt a kproc blocked on a network read.
The update messages generated by spree are as follows:
Note that a given client does not have to interpret all the above messages - different client types have their own conventions. The card client type uses most of the above functionality, for example, whereas a client for the chat engine listed in spree(2) can get away with interpreting only one message, the custom action chat.
Writes to the opened clique file are interpreted as clique actions by the clique that has been loaded, and acted on accordingly. Invalid actions will draw a write error.
mount tcp!somehost.com!3242 /n/remote { echo create chat >[1=0] cat & cat >[1=0] < /dev/cons } <> /n/remote/new
SPREE(4 ) | Rev: Thu Feb 15 14:43:41 GMT 2007 |