[Portland] The Code

[nf2]

Hi!

Lubos Lunak wrote:
> On Thursday 16 February 2006 19:17, Bryce Harrington wrote:
>   
>
>>> It may be feasible to have different short term and long term solutions,
>>> although I'm not sure how that would work out. But it would be
>>> interesting to start with a simple IPC mechanism as used by Lubos and
>>> target a Dbus based solution down the road.
>>>       
>
>  If I abstract out the socket handle to something opaque I should be able to 
> somewhen later change the autogenerated code to use DBus or whatever, so 
> assuming servers keep supporting the old system and more importantly assuming 
> the transport mechanism would be the only thing to change, apps wouldn't even 
> have to notice or bother.
>
>   

Yes, i think the best thing would be to standardize the API not the 
protocol. The API should be as generic as possible. Things like 
file-descriptors should not be exposed to the user. Therefore 
dapi_open() should return an opaque struct like:

typedef struct {} DapiHandle;

IMHO libdapi should never be linked statically, because that would make 
any future improvement of the internal implementation (IPC) very hard.

Another problem might be asyncronous calls. Things like file 
upload/download might take long and therefore should be non-blocking and 
report progress and success async.

Because the common-main loop doesn't exist (yet), perhaps passing 
main-loop adaption functions to DAPI would work:

typedef struct {} DapiMainloopAdapter;

typedef struct {
    DapiMainloopAdapter * (*init)();
    void (*watch_fd)(DapiMainloopAdapter *, int fd, short events, 
void(*callback)(short revents, void * userData), void* userData);
    void (*remove_fd)(DapiMainloopAdapter *, int fd);
    void (*set_timer)(DapiMainloopAdapter *, int msec, 
void(*callback)(void * userData), void* userData);
    void (*destroy)(DapiMainloopAdapter *);
} DapiMainloopAdapterFunctions;

DapiHandle * dapi_open(DapiMainloopAdapterFunctions *);

The advantage of this model might be that it's transparent to the user 
how and how many fd's DAPI needs to watch internally. Of course a 
GSource style adpater would be nicer, but i'm afraid Qt doesn't support 
that at the moment.

The IPC:

If you don't want to move to dbus at the moment you could also use my 
"LVariant" library for serializing things over the wire. I have just 
added serialization functions. The advantage is that it's quite simple 
and just requires two files (lvariant.c and lvariant.h) to be shipped 
with your sources and it supports more complex data types and structures 
(arrays and maps).

The dapi wire protocol could look like this:

DapiMessage: [ int magicNumber | int commandID | int bodySize | char[] 
body Data  (serialized LVariant array of args)]

http://www.scheinwelt.at/~norbertf/dadapt/files/

LVariant might help to assemble IPC messages in a buffer. The reason is 
that for an async/non blocking interface you have to return to the 
main-loop after every write() and read() call until a complete message 
has been sent or has arrived.

regards,
Norbert