1.0 ABI guarantees, static linking, reimplementation

[John (J5) Palmieri]

On Fri, 2006-10-27 at 22:03 -0400, Havoc Pennington wrote:
> Hi,
> 
> We need to describe the interface stability policy in the README and so 
> forth when 1.0 is released.
> 
> One question in my mind is whether we are ready to lock down the ability 
> to statically link or reimplement.
> 
> That is, 1.0 definitely freezes the ABI and semantics of libdbus the 
> shared library. Also, the protocol from libdbus to the bus or other apps.
> 
> However, to let people statically link and/or reimplement the library, 
> we have to also freeze:
>   - the locations/semantics of files read by the library
>   - the essential environment variables read by the library
>   - similar stuff
> 
> And to let people reimplement the bus, we have to freeze / document the 
> bus features that apps might rely on, the main one is .service files, 
> also ability to install security policy config files for the system bus.
> 
> That's four different interface guarantees:
>   - shared object ABI
>   - protocol and bus exported interfaces
>   - interface from the shared object to the system (files, env variables)
>   - interface from apps to the bus (policy files, .service files)

I'm going to make a separate about this but one of the things we found
out in OLPC is we want the ability to define a servicedir based on a
users home directory so we can have drop in bundles that are activated
via D-Bus.  Also there has been talk of merging .service files
and .desktop files.  I'm not sure if that is good or not but I don't
think these parts of D-Bus have been fleshed out enough.

> My opinion is that the minimum for 1.0 is:
>   - shared object ABI
>   - protocol and bus exported interfaces
>   - .service files for session bus
> 
> However, if we don't think it's ready, I consider it fine to document as 
> not-yet-frozen:
>   - interface from the shared object to the system
>   - bus configuration and policy files
> 
> This would basically mean that static linking is a bad idea. I'm pretty 
> sure static linking _is_ a bad idea whether we freeze these things or 
> not, but that's another story I guess.

I believe Skype statically links 0.22 in. I would say at minimum we
would want someone who statically links libdbus to be able to get on the
session bus, talk to the session bus and have others talk to it.  As far
as policy files go, they haven't really been used extensively to know if
they are ideal.  However we should make our best efforts to keep them
forward compatible.  

> I don't know whether the interface from the shared object to the OS is 
> ready to freeze or not, to be honest. As Thiago has pointed out, it's 
> not yet very well covered by the spec. We also have the outstanding 
> uncertainty about /var/lib vs. /var/run.

It is an interesting conundrum.  Without locking these down now things
like managed dbus won't be able to reliably write a daemon and may go
down its own path but locking them down now presents the scenario where
we may have not made the best choice for locations.  

> On the other hand, I don't think this interface is very big. It's 
> probably only a couple files and a couple env variables.
> 
> Don't know. However, for 1.0 we should spell out in detail what's frozen 
> and what isn't, and whether static linking is "safe," in the docs.

We can lock this stuff down for 1.0 and say that 1.2 is allowed to break
compatibility if the necessity arises.

-- 
John (J5) Palmieri <johnp at redhat.com>