[Portland] libdapii

[nf2]

Hi!

Inspired by Lobos Lunaks 'dapi' i have started coding a slightly 
different implementation to:

* be able to write non-blocking clients and daemons (message queues and 
callbacks)
* be able to implement 'JOBS', for operations which take longer 
(file-uplaod/download)
* be able to exchange messages while a JOB is running like 
progress/cancel -signals
* to read/write file-data via the socket

it's called libdapii and can be downloaded from here: 
http://www.scheinwelt.at/~norbertf/dadapt/files/
i have not startet porting the whole thing (KDE-daemon...) yet, so it's 
not fully working like Lobos Lunaks stuff. It's very sketchy at the moment.

to autogenerate the API and communication stuff
cd lib/autogen
./gen.py

The protocol i'm currently using looks like this:

FUNCTION OpenURL
  MSG_COMMAND 100
    ARG url string
  ENDMSG
  MSG_REPLY 101
    ARG errtext string
    ARG ok bool
  ENDMSG
ENDFUNCTION

JOB DownloadURL
  MSG_COMMAND 200
    ARG url string
    ARG localfile string
  ENDMSG
  MSG_BACK 202 Progress
    ARG bytecount int
    ARG progress int
    ARG mime string
  ENDMSG
  MSG_TO 203 Cancel
  ENDMSG
  MSG_REPLY 201
    ARG ok bool
  ENDMSG
ENDJOB

A function or job at least has to define a COMMAND message 
(client->server) and a REPLY (server->client) message.
Additionally a JOB can define TO messages (client->server) and BACK 
messages (server->client), which can be sent during a JOB.

For the wire protocol i'm using vio_trans and lvariant which can be 
downloaded from the same place (they could be shipped with dapii in the 
future...)

A dapii message looks like this:

{ int magic; int msgID; int bodySize; char[] body }

Every message has a msgID (int) defined in the protocol.

the body contains a serialized LVariant (containing a list of args), but 
could also transport raw data (like file-data for file-get/put jobs)
One reason for moving to something like LVariant would be to ease 
serialisation of advanced types like key-value maps (for sending 
direntries, metadata etc...) and being able to serialize/unserialize 
messages into/from a buffer, which - i think - is necessary for 
non-blocking IO.

What do you think...

Cheers,
Norbert