memory freeing necessary?

[David Zeuthen]

On Tue, 2006-07-25 at 10:37 -0400, Havoc Pennington wrote:
> >> It's OPTIONAL for services to install introspection data, but if they
> >> do it needs to be stored in
> >>
> >>  /usr/share/dbus/introspection-data/<service-name>/<interface-name>.xml
> >>
> 
> I would not include <service-name> here - well, first it should be bus 
> name, can somebody audit the word 'service' out of the dbus source tree 
> so we can get rid of this word that misleads the hell out of everyone ;-)

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. 

> But even so, conceptually what I'd think we're installing is an 
> interface. I might even suggest:
>   - the file must be named after the interface
>   - only one interface per file
>   - no paths or objects allowed in the file

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?

So, is anyone opposed to the location

 /usr/share/dbus/introspection-data

where HAL e.g. will dump files

 org.freedesktop.Hal.Device.xml
 org.freedesktop.Hal.Device.Volume.xml
 org.freedesktop.Hal.Device.Volume.Crypto.xml
 ...

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?

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!

Other questions:

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

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

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

    David

[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

 - you can add signals to an interface

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

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

 - 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

 - other?

p.s. : sorry, I'm way behind on dbus list so if anyone proposed
something different or better please point me to it. Thanks.