[Portland] Current plan summarized

[Kevin Krammer]

On Wednesday 15 March 2006 11:47, nf2 wrote:
> I'm still not convinced regarding the static linking of the interface
> library. We have not discussed this thoroughly and perhaps it's too
> early to decide. I think there are two options here:

Static linking has the advantage that starting an application on a system 
without "DAPI" support will not fail due to unresolved symbols.

Of course there is always the possibility to have the API part of the library 
statically linked and the IPC part dlopen'ed.

> 1) Standardize protocol, socket locations, dapi-daemon startup-scripts...
> 2) Standardize the API of a dynamically linked dapi-client library (You
> can still have convenience wrappers for C++,...), hiding all the IPC
> complexity.

As long as the API specification stays within bounds of complexity that allows 
generation of bindings, I'd prefer the first one.

Providing the base implementation for something that is meant to be wrapped is 
IMHO a lot more work than a normal implementation because the base 
implementation cannot make any assumptions about restrictions implied by the 
binding language/library.

As an example it is not recommended for DBus to use the DBus library directly, 
even C developers are encouraged to use the glib bindings.

Cheers,
Kevin
-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060315/0a7bffc6/attachment.pgp