HAL 0.1 release

[Joe Shaw]

On Thu, 2003-10-09 at 16:20, David Zeuthen 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. 
> 
> 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).

Yeah, definitely I think Category is useful.  But I think it's most
useful to be able to list multiple categories and then forego
SubCategory entirely.

For example, for my camera, it's both a storage device and a camera. 
But it's entirely possible that my camera isn't a storage device, and
obviously there are storage devices which aren't cameras.

Maybe it's more helpful to think about them as capabilities rather than
categories.  Or as Chris Blizzard just put it to me on IRC, "what can it
do" rather than "what it is".

> The SubCategory is to aid applications telling more about the device,
> such as a possible modem init string or ethernet MAC address.

Hmm, I'm confused now.  Wouldn't these things be expressed as properties
on a device?  For the modem, the category could be "Modem" and the init
string would be included in the device info file.  For a network
adaptor, the category could be "Ethernet" and the MAC address would be
through some hardware detection.

(Hmm, a question to consider is whether a PPP connection on a modem
should also be a "network adaptor" shown in the HAL, but that's a
different argument...)

> 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.
> 
> It's there so we can, programmatically, distinguish between USB keyrings
> and USB cameras appearing as storage in the UI.

I think that just "Category" should be enough for this, though, no? 
When (and why) would something be a "Camera" in Category but not be
"Camera" in UserCategory?

I can envison an API being something like:

HalDevice **get_devices_by_category (const char *category_name);
boolean     device_has_category     (const char *category_name);

So that for the file manager you could either get a list of devices
which have category Camera, or alternatively walk the list of Storage
devices and see if any of them additionally is a Camera.

> HAL should not do auto-configuration of devices - except for maybe
> helping in mounting hotpluggable storage - that's my example in hal 0.1
> but it's only an example.
> 
> But I think the idea of using HAL as a repository of information about a
> device is sound - the idea is really from Havoc: to merge a lot of
> information from different sources.

Definitely.  I agree with this 100%.

> Discover does the same; they store information about what XFree86
> parameters to use.
> 
> The idea is really that software like XFree86 can read this information
> from HAL, and then do *their own* autoconfiguration.

Yeah, you're right about this... XFree86 is a special case where this
would make sense.

> It's more useful to make hald use libusb/libpci directly and I'm close
> to committing code to CVS that actually does this.

Word.

Joe