Roadmap?

[David Zeuthen]

On Tue, 2003-10-14 at 16:45, Havoc Pennington wrote:
> > Which means, in the context of hal, libhal is not useful for glib, Qt
> > and python programs. Such programs simply just access the device objects
> > and a single object at "/" for getting the device objects. Very useful.
> 
> libhal may or may not be useful. For example it might be useful
> basically as an implementation of a local cache of the device list and
> each device's properties, to avoid a bunch of remote round trips.
> 

Now this I would recommend against, round trips can be mostly avoided
see below.

I think for hal to be useful, there needs to be bindings to many
languages. I really want to avoid maintaining libhal for glib, Qt,
python and so on if that can be avoided. So the IDL stub generator will
take care of that...

OTOH, I think a single libhal for plain C apps is neccesary so as to
insulate the users from dealing with dbus details. Unless of course
someone writes a IDL stub generator for plain C (which I expect to be
happening any time soon).

> You may want to make each device object an actual object, either with
> arbitrary names or in some kind of meaningful tree:
> 

That's the plan. Each and every device will, to avoid a lot of
roundtrips, support the org.freedesktop.Hal.Device interface with a
method getProperties that returns all the properties.

(which is why I want to still have the dict data type; see the other
thread).

So this would entail N+1 roundtrips for N devices to show the full
device tree which is fine enough, yes?


> Or perhaps instead of 001/002 something that won't change as devices
> come and go; perhaps base the name on some unique device features, 
> maybe "orinoco-pcmcia-001" or something.
> 

That's already done - *some* devices even sport a unique serial number
(unique to the instance of the device) that may be used, but I yet have
to see some of those devices. 

The device names will not be that helpful for human beings, but they
will be as unique as possible between device insertions.

> I wouldn't use "/" because you may want to add other stuff someday.
> 
> > Unless object discovery (e.g. give me all objects from service Foo
> > implementing the org.blah.Bar interface) is supported?
> 
> You're free to implement such a method. It isn't in libdbus because it
> would require registering all objects in a central repository and the
> decision was to avoid that bloat.
> 

Initially, I'll probably supply an object at the path /org/../Manager
with getAllDevices() and getDevicesWithCapability(array<int>) methods
etc.

I understand you don't really want to implement name servers and such
even though it could be nice especially for hal. 

E.g. it gets more interesting when someone offers a service (possibly
activated when needed) supplying the org.freedesktop.Hal.Camera
interface with the methods getPictures(). The photo-app author would
simply pass the device object that it got from the hal service to such a
service and get the job done :-).

So it's basically about moving functionality apps today use from
libraries into objects. The nice touch is that this gives network
transparency for free and removes library dependencies from
applications. The bad part is of course roundtrip time / bandwidth
needed (even on a local machine)...

But now I'm rambling and/or on crack :-) First things first..

Cheers,
David