HAL 0.1 release

[Joe Shaw]

On Thu, 2003-10-09 at 14:33, David Zeuthen wrote:
> Yeah, 'bus class' is much akin to Category. I found it's been useful to
> think in terms of three different classifications
> 
>  Category    = Storage, Network, Video, Camera etc.
> 
>  SubCategory = Magnetic, Optical, Flash, Zip,  # For 'Storage'
>                Ethernet, Modem, ATM, ADSL      # For 'Network'
>                ,                     # For 'Video' (can't think of any)
>                ,                     # For 'Camera' (can't think of any)
> 
>  UserCategory = <same as category>
> 
> So only Category is mandatory. SubCategory, UserCategory is optional.
> The interesting is UserCategory as this is what the UI parts will use. 
> 
> One example of where UserCategory is of benefit is to consider digital
> camera support on Linux today. So, some cameras appear as usb-storage
> and we want to distinguish them on the UI level with an icon.
> 
> I think it's useful this way, and it can (almost) be done with both
> options A and B. Note that the category / subcategories are not yet
> defined and we could do this together.
> 
> A: We simply map busclass to the appropriate category / subcategory set
> 
> B: Introduce Category, SubCategory, UserCategory through the <data> tags

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.

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

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.

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

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

Joe