HAL 0.1 release

[David Zeuthen]

On Thu, 2003-10-09 at 22:32, Sean Middleditch wrote:
> > The point is that the Category property is quite important because e.g.
> > if your category is Storage you need to have a property called
> > Storage.KernelDevice, which is the /dev-file for accessing the device. 
> 
> And what is it about having multiple categories that defeats this?
>
> > If your category is Camera you may contain other properties such that
> > e.g. libghoto can use the Device object or things from this object
> > (today this would just be the usb.* parameters).
> 
> Right, but if your device is *both* a camera and storage, and Mr. Shaw
> said, what are you to do if you only have one category?
> 

My initial attempt was by introducing UserCategory, but I think the
notion of capabilities, as cover elsewhere in this thread, is much nicer
and actually sets the desktop environment in the drivers seat when it
comes to using devices.

> > 
> > The SubCategory is to aid applications telling more about the device,
> > such as a possible modem init string or ethernet MAC address.
> > 
> > It's all about having a minimal, yet useful, set of well defined
> > properties about the device.
> 
> What exactly does SubCategory actually provide, tho?  Why can't you just
> have the modem init strings for any device that has the category Modem? 

Oh, this is because I think of a modem as having Category=Network in
much the same was as I think of my ethernet card being Category=Network.
So I want to convey the difference of these devices through subcategory.

> Why do you need extra heirarchy?  Doesn't heirarchy make certain things
> impossible?  Look at the LDAP design - an object is composed of multiple
> classes (Categories, in HAL) which have their schemas - you can have
> both the orginationalPerson and the nisPerson (or whichever the object
> classes are named) in one object, and combine the properties of both
> schemas.  You can refine by adding extra classes, and you can make the
> objects more powerful/flexible by not being stuck in a heirarchy of
> classes (categories).
> 

Well, yes. But for objects in the device tree, we do tend to be able to
speak of categories of devices; networking, storage etc.

As Eric points out this is also how hardware vendors think of devices:
class, subclass. So (category, subcategory) is really just what discover
calls busclass which has the class in the upper 8 bits and subclass in
the lower 8 bits, AFAICS.

> > > As for "UserCategory", I don't think it has a lot of use cases. 
> > > Generally, I think that the majority of the actions based on a category
> > > would happen programmatically, and if the user wanted to identify the
> > > camera, the name "Olympus Zoom blah blah blah" is a lot more useful than
> > > the category.
> > 
> > The sentiment for including UserCategory is simply to let a file manager
> > choose a camera icon and let photo applications know that this storage
> > device actually is a camera - it would then access it using standard
> > filesystem API's instead of the e.g. USB api's if the category is USB.
> 
> But if it *is* a USB storage device...  Lots of people use their MP3
> players for storage these days if the device lets them.  If you only
> have one device type, i.e. MP3 Player, then they wouldn't have
> convenient plain storage access.
> 
> By letting the device have multiple categories, MP3 Player *and*
> Storage, we can now show the storage device on the user's desktop like
> any normal media, plus we can pop open whichever app the user has
> configured to handle MP3 Players (perhaps Rhythmbox in the future).
> 
> You can also get functionality by having rules match multiple categories
> - i.e., if its just a Storage device, open Nautilus.  If it's a
> Storage/MP3-Player, open Nautilus in Music Browing Mode (or whatever). 
> If it's just an MP3 Player,open Rhythmbox.
> 
> This gives us finer control than the heirarchy in some cases.
> 

Yeah, this is really capabilities which is a much better word.

> > And this actually allows free desktops to help the user configure a
> > device, e.g. if no device info file is known you ask "What did you just
> > plug in?". User selects video card and then the required properties for
> > video card  (which are well known because they are in the spec).
> 
> Slightly different tangent - would an online reposotiry of information
> be possible?  I can imagine a user wanting to use a device that came out
> after his OS was installed; the installed database would have no
> knowledge of the device, but the online repository might've had it
> added.  An option like, "Search FreeDesktop Hardware List for periphial
> identity..." in the unknown hardware dialog would rock.  

This would really rock, I agree. Web services and all that. I think that
most of this infrastructure is already in discover today, you just
specify a http:// URL in discover.conf, right Eric?

> Especially if
> it could then identify that certain pieces of software needed updating,
> and *sanely* tell the user about it (or better, plug into the system
> package manager and grab the updates; say, w/ up2date on Red Hat).
> 

This would rock even more. The use case I had in mind was either distros
or, at some point, OEM's providing packages with all the driver software
and also a device info file.

Cheers,
David