HAL 0.1 release

[Sean Middleditch]

On Thu, 2003-10-09 at 16:20, David Zeuthen wrote:
> On Thu, 2003-10-09 at 21:41, Joe Shaw wrote:

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

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?

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

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

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

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

> 
> (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
> 
> _______________________________________________
> Xdg-list mailing list
> Xdg-list at freedesktop.org
> https://www.redhat.com/mailman/listinfo/xdg-list
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.