memory freeing necessary?

[David Zeuthen]

On Sat, 2006-07-22 at 18:11 +0100, Richard Hughes wrote:
> I've got quite a nice libhal-glib implementation if you think this is
> useful to have in hal. It's a standard singleton gobject, so desktop
> applications can just receive standard signals on a gobject and not have
> to worry about dbus at all (as some of the stuff like using
> PropertyModified is pretty gruesome...)
> It's pretty lightweight, and converts the odd types such as char ***
> into 'friendly' GLists and other nice stuff.
> 
> What you think? Want a patch?

How does this compare to generating code using our introspection XML and
dbus-binding-tool?

Oh, and, another point is that we should probably install the
introspection XML somewhere so distros can ship it as part of the
hal-devel (or what they choose to name it) package and it can be used
for BuildRequires. I'm way behind on the dbus list, last time I checked
there was no specified location and naming structure, e.g. the dbus spec
could say:

 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

so we would e.g. install

 /usr/share/dbus/introspection-data/org.freedesktop.Hal/org.freedesktop.Hal.Manager.xml
 /usr/share/dbus/introspection-data/org.freedesktop.Hal/org.freedesktop.Hal.Device.xml
 /usr/share/dbus/introspection-data/org.freedesktop.Hal/org.freedesktop.Hal.Device.Volume.xml
 /usr/share/dbus/introspection-data/org.freedesktop.Hal/org.freedesktop.Hal.Device.Volume.Crypto.xml

and so forth.

We probably have to generate and maintain the XML by hand cuz some of it
comes from weird add-ons :-) - but that's more of our problem because
we've chosen to an extensible architecture. In reality it's not a big
deal because we want these interfaces to be stable and not change.

    David