Basic protocol
--------------

Each client or brain line is a one-line JSON array.

Brain lines:
['initial',['#1', '#2']] -- expose initial objects
['answers', '#cmd1', [['#3', 'OK', 'ok'], ['#4', 'Int', '123']] -- asynchronous answers to a command, each object with type and desc
['info', [['#3', 'OK', 'ok', '']]] -- answer to info request
['error', 'copy of line', 'error text'] -- report error in the client line

Client lines:
['cmd', '#receiver', commandAsFreeJSON] -- send command
['forget', ['#3', '#4']] -- discard object references
['exit'] -- complete this talk
['info', ['#3']] -- get info on objects (type, description, command help)
['info', '#3'] -- shorter syntax for only one object

Commands are numbered from 1 up per talk (#cmd1, #cmd2 etc), so there is no need for the client to transmit the ID.


Advanced notes
--------------

The protocol can be used bidirectionally if you like that sort of thing, with both parties being client and server (or the 'brain'). The two different 'info' lines (request vs answer) can be distinguished by the argument format (just id or id plus 3 more fields).

Using the protocol bidirectionally in one connection could also allow the client to introduce itself via an initial object. Whatever the format for that is. Maybe "#i-am" with type "IAm" and description "brain client bla version x running on this and that server".


Update
------

We almost don't need the info command at all, since thing descriptions are now returned in all command answers. This leaves only the "help" field which is not really used yet. So "info" currently has no actual purpose.