HAL-Managers

[David Zeuthen]

On Wed, 2005-02-09 at 22:39 +0100, Kay Sievers wrote:
> > I definitely think they have to provide their own "view of the world" as
> > in "using HAL is an implementation detail" (but for me it of course
> > makes sense for them to use HAL, otherwise they'll need their own
> > solution for merging arbitrary information with hw (.fdi files), set up
> > hotplug agents etc. etc.)
> 
> Ok, but how can applications know where to get that from? 

Presumably they would talk to com.foo.SomeService like certain apps are
talking to the org.freedesktop.Hal service today.

> Wouldn't it be
> nice to have only one store with common access/subscription methods,
> where the "Managers" store device objects in and applications can query
> that.
> 

I don't know - first of all it wouldn't be "device objects" - for
instance, for printing, one could patch CUPS to provide a D-BUS service
along with objects on the system message bus; the objects exposed would
be "printer objects", "print job objects" and so forth. There would be a
root object (like we have /org/freedesktop/Hal/Manager) with
GetPrintJobs() to discover other objects.

> > Look at NetworkManager - it knows (or it will) about
> > 
> >  - Networking devices (which it got from HAL)
> >  - Available networks (there may multiple wireless networks available;
> >                        you only have a network on a wired device if
> >                        there is link/DHCP server)
> >  - Tunneled connections such as VPN connections which needs to be
> >    treated in a special way
> 
> Sure all this needs to be treated in a special way, but does it really
> need not to be represented in a special way? I expect a lot of competing
> things here, if we don't provide some sort of centralization.
> 

I think it make sense to treat this in a special way as noted above,
yes. 

> So wouldn't it be nice if CUPS as an example exposes its list of
> printers in the same form as HAL device objects, so an application may
> ask some central instance where to get that list. The same question
> applies to nearly all "capability" groups of devices.
> 

Well, that sounds like something you should propose to the CUPS
developers then. From what I know, their not happy about adding extra
dependencies even though it would be a compile-time option. I could be
wrong though. 

<evangelism_and_tech_pimping disclaimer="my own personal view">

Btw, the way free software works is that anyone can just fork a project
or write a wrapper that provides the D-BUS service for a project :-).
So, if I'm distro XYZ, I provide the com.XYZDistroCompany.Cups service
and patch my desktop to use it. 

Now, if the GNOME and KDE people decides the true way to interact is
through D-BUS, they may just agree that now it's called the
org.freedesktop.Cups system bus service or whatever and work together on
maintaining that patch-set or fork (and if they're nice, as such people
normally are, they do copyright assignment back to the original
project). Distributors can then pick that up if they want to. 

If it's really a good idea and the D-BUS interface adds a lot of value,
I don't see why it couldn't go into upstream some day.

> We will get more and more virtual things, which should be handled in a
> sane way from the beginning on. I don't talk about including all this
> into HAL, we've already been there, but I really see the need for a
> solution here.

I agree, but note that's pretty much what D-BUS is all about. Indeed,
it's pretty difficult _not to_ end up with the model described above;
services, objects, interfaces - all that jazz - that's the power of
having a framework. 

HAL just happens to be one of the first users of the system-wide bus;
more will come soon I hope. D-BUS really rocks and I'm positive it will
save the day :-)

</evangelism_and_tech_pimping>

Cheers,
David



> 
> Thanks,
> Kay
> 
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal