[Portland] libdapii

[Lubos Lunak]

On Saturday 25 February 2006 16:06, nf2 wrote:
> 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

 Hmm. What exactly should be the advantages of your unfinished solution to my 
unfinished solution? (I don't mean to be sarcastic or anything like that, I'm 
simply asking.)

> The protocol i'm currently using looks like this:
...
>
> 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.

 I like (besides the Python generator) some of the ideas in the C API. As far 
as the C API goes, that is. I don't see any advantage for e.g. Qt/KDE code - 
easy serialization of advanced types will suddenly become error-prone and 
cumbersome, C-style callsbacks as well, and so on. And yes, I'd eventually 
want to make the code generator generate also Qt bindings for use in Qt/KDE 
apps (and others too if needed/wanted). And it seems simpler to me to modify 
the generator to generate it again from scratch to fit whatever requirements 
there will be rather than trying to wrap it to C API.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/