[Portland] Current plan summarized

[nf2]

Kevin Krammer wrote:
> 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.
>   
Perhaps a "strong" package dependency would be ok. Otherwise the 
application developer has to deal with another fallback-case.
>   
>> 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.
>   
We will see. Async stuff is not trivial and Lubos code is not truely 
non-blocking yet. It's going to be quite a lot of code to write and 
debug if you reinvent the dapi client wheel several times.
> 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.
>   
Why not? There are a lots of bindings for the gtk stuff for instance. 
I'm not sure what's the requirements for that. Just having reference 
counters? Someone here who knows more about that topic?
> 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.
>   
That's what's so sad about dbus. You can't use it inside in a shared 
infrastructure library.*) Abstraction, modularization and code-reuse is 
essential for every modern computer system - and on linux/unix you just 
can not have it because of this stupid main-loop-problem?

*) Well - maybe dbus can be used without bindings and instead pass a 
generic main loop adaption object through the dapi library. I'll be 
investigating that.

Cheers,
Norbert