first cut of hal service description file

[David Zeuthen]

Hi,

Attached is a pretty rough first cut for the various D-BUS objects and
interfaces supported by hal. Ideally, I'd specifically like to use this
file to

 - deprecate libhal and port desktop apps to use the D-BUS bindings
   generated from this XML file (and maintain libhal ABI compat even
   though we break the D-BUS ABI in hald)

 - replace the existing D-BUS marshaling/demarshaling code in hald

in that order. 

Here are some initial thoughts/questions

 - I couldn't find how to describe what signals to emit so I just
   assumed <signal> was the way to go; does this make sense?

 - Exceptions; since we're going to generate client side code for
   languages/runtimes that support exceptions we need a way to annotate
   what exceptions a method can throw; e.g. in pseudo-code

     using namespace org::freedesktop::Hal;

     class Device {
       void Lock() throws NoSuchDevice, PermissionDenied,
                          DeviceAlreadyLocked;
     };

   I just added comments about what hald can throw at you today.

 - As noted for objects implementing the org.freedesktop.Hal.Device
   interface, there is no way to know a'priori what objects these are
   except perhaps that they reside in a certain name space. 

   One of the common use cases is that client code gets an object_path
   (hal example: a newly added storage device) and wants to listen for
   events (hal example: for when the device is mounted). Another use
   case is that client code just want to invoke a method (hal example:
   check some properties, then stop caring about the object).

   Today, this requires that the client code maintains the lifecycle
   for DBusGProxy object, specifically, to invoke methods on the
   object we need to construct a new DBusGProxy object, call the
   method, and then possibly dispose the proxy. 

   Any chance we can have some kind of proxy manager so it becomes
   even easier to write client code? Ideally, I'd like to be able
   to just pass the object_path to the generated function...

 - Where am I supposed to ship the hald.xml (and should it be named
   hald.xml) at all? In -devel or the runtime package? I guess this
   can be answered by answering these questions

   - do we expect certain languages/runtimes to load the hald.xml
     file at runtime to generate proxies on the fly? (Java, Mono
     comes to mind). If yes, we need to ship it with the runtime
     package (hal.rpm)

   - do we expect certain languages/runtimes to consume the hald.xml
     file at build time? (glib comes mind)

   I suppose the answer to these questions are both yes.

 - To deploy the hal service in a message bus scenario, I still need to
   write a policy file; would be crack to generate this from the service
   description file using annotations?

 - I've used the term 'service description file' throughout this email
   as I wasn't really sure what it's called :-) - we probably need a
   glossary before 1.0 (if we don't have one already).

Oh, I haven't tested this at all since the dbus-binding-tool currently
only supports primitive types.

Cheers,
David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hald.xml
Type: text/xml
Size: 13058 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050331/c86fee63/hald.bin