[Portland] The Code

[Lubos Lunak]

On Saturday 18 February 2006 22:09, nf2 wrote:
> Hi!
>
> Lubos Lunak wrote:
> >  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.

 If I'm not mistaken many ISVs want to link everything statically so this is 
an even harder conflict here. Moreover I don't think it'd be a good idea to 
change the IPC often anyway, it needs to be made extensible from the 
beginning and something like starting with sockets and later switching to 
DBus if needed should be the maximum allowed (and IMHO also needed). In which 
case the server handling both protocols would just do.

 Finally, it could be nice to have libs like Qt include code for handling the 
wire format directly instead of linking to a silly little .so that does 
almost nothing. The performance guy in me always winces at the sight of libs 
like libXfixes or libXdamage and I don't think I want to add more.

>
> 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.

 Right.

>
> 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.

 Given that in client apps there should be at most one filedescriptor this 
seems like an overkill to me.

> 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.

 Hmm, I'm not sure. There should be many rather strong guarantees here - 
messages have known size and format, so there shouldn't be any need to add 
data types to the message, everything is done on localhost, so there 
shouldn't be any communication problems either. It should be kept simple, the 
question is perhaps just if this is not too naive.

-- 
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/