memory freeing necessary?

[Havoc Pennington]

David Zeuthen wrote:
> Right. OK. Slight concern that someone writes e.g. three services (one
> on the session bus, one on the system bus, one for peer to peer use)
> that provides interfaces with the same name but different syntax and
> semantics. But, then again, anyone can do stupid things, we can't really
> prevent that. 

We could in principle have separate directories for each bus, but I 
think it might not be worth it.

> Sounds good to me. This works because we already require, or at least
> encourage  the interface names to be prefixed by the "domain name" (e.g.
> dk.fubar, com.redhat or org.freedesktop.Hal) or some other suituably
> unique identifier.
> 
> If we only encourage prefixing the domain name, maybe we should change
> it to a requirement - where is this specificed btw?

It's in dbus/doc/dbus-specification.xml

I think the requirement enforced by the code is just "the interface name 
has a period in it" and then the spec requires that it be the reversed 
domain name deal.

> So, is anyone opposed to the location
> 
>  /usr/share/dbus/introspection-data

What about datadir/dbus/interfaces ?

Where datadir is the usual XDG_ search path thingy.

> and other services do the same? Should the file extension be ".xml". Or
> do we want a dbus specific one, e.g. ".dbus-introspection-data"? What's
> the MIME type going to be (for example what about
> "application/dbus-introspection-data" or do we not need one?

I don't know here, what do other apps do?

> Where should we put these guidelines / requirements ? In the dbus
> specification? I can write up a patch if you or someone else can point
> me to the exact file!

dbus/doc/dbus-specification.xml (to build it to html, install "xmlto" 
before you run configure)

You might follow the thread for a couple more days before writing, in 
case people have more input...

>  - Should we require or just encourage apps to drop files there? Some
>    apps are not really are introspectable (hal just gained this in CVS
>    HEAD a month or two ago, NM still don't IIRC) and some never will,
>    so suggest to not require it.

I think encourage.

>  - Should we encourage distros carry introspection data in -devel
>    packages or the real packages? I don't really know.

I would say -devel, at runtime Introspect() on the bus should be used.

>  - How do we go about versioning? I think the conclusion was that
>    if you break ABI [1] you need to rename the interface, e.g. 
>    move to org.freedesktop.Hal.Device2 the MS COM way. This should
>    probably be written down too if not already.

There were some more complex proposals in prior threads, but until 
someone goes back to those, summarizes, patches spec and patches code, 
I'd say the default is that you should rename.

> [1] : We need to specify (or at least write down) how interfaces can be
> extended without breaking the ABI. E.g. I think the consensus is
> 
>  - you can add methods to an interface

This will break C++ ABI I believe ... though, if we say "no including 
generated dbus interfaces in library APIs" (which I consider a good 
idea) then dbus interfaces only need to preserve source/wire 
compatibility, not the ABI of all possible bindings.

So, we may want to specify this "source compat only" guarantee.

>  - you cannot change the semantics of a method or signal
> 
>  - you can add exceptions to any method (since you decided to shoot
>    down my ideas of exposing what exceptions a method throws)

I think I actually said "exceptions are part of the defined semantics of 
a method, even though they aren't in the type signature, and you have to 
specify non-compiler-checked semantics in an ABI anyway and exceptions 
would fall under that spec"

IOW exceptions can't be added if they break the semantics, so your 
previous bullet point applies ;-)

>  - can you add IN parameters to methods / signals? In the C ABI you can
>    do this

This would break source compatibility.

We may want to change dbus_message_get_args() (and corresponding 
routines in the glib, etc. bindings) to throw an error if there are 
extra args so people don't do this... one for the TODO

>  - can you add OUT parameters? In the C ABI you make a function
>    returning "void" return something provided, of course, you don't
>    need the caller to free it

Seems like a similar case of may break source compat though it doesn't 
break wire compat.

Seems important to keep clear terminology in any specs/proposal-writeup 
regarding generated source API compat, generated bindings ABI compat,
and wire compat; and be clear which are guaranteed.

Havoc