HAL 0.1 release

[David Zeuthen]

On Thu, 2003-10-09 at 21:41, Joe Shaw wrote:
> Hmm, this all seems a little over-complex to me, or perhaps I'm not
> understanding the problem that you're trying to solve here.

Hmm, maybe I'm over complicating things, I'm not sure; please let me
know.

In either case, I'm happy to have a discussion about the scope of HAL.
As mentioned earlier I think HAL should be lean and mean and not try to
do a lot of things. But we also need a baseline of what is required
right now to provide hardware support comparable to other desktops.

> It seems to me that you could probably provide a list of categories that
> the device is.  For example, when I plug my Olympus digital camera into
> my Mac, two things happen:
> 
> 	* The storage is mounted and an icon appears on my desktop
> 	* iPhoto launches and imports my photos
> 
> So it would seem to make sense to me that my camera would have "Category
> = Storage, Camera".

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).

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.

> 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.

It's there so we can, programmatically, distinguish between USB keyrings
and USB cameras appearing as storage in the UI.

> > In general most of fields that is specified with the data tag should
> > follow the HAL / Discover specs.
> > (HAL specifies something for Storage, while Discover specify the XFree86
> > parts)
> 
> I'm not sure that using the Discover format is really what we want
> here.  Based on the example device you posted, there seems to be a very
> little bit of data used for matching at the top, but the majority of the
> data there is for configuring software, and that seems like something
> that should be done totally separately from HAL... 

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.

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.

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).

(XFree86 is of course just an example - Yes yes, I know it's pretentious
that XFree86 would be using hal anytime soon or later)

> ie. Discover can keep
> doing it, but instead of having to detect it itself it could use the
> Device object and its properties available to it via libhal.
> 

Yes this could be split into two or more programs. I just think it is
more practical to have it in one program.

> That said, though, the detection stuff in the Discover files is probably
> pretty useful, and you could pretty easily write a script to parse that
> info and output another file which could be used to map that stuff in
> HAL.  (But other things like libusb/libpci might be better for that, I'm
> not sure.)
> 

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

Cheers,
David