HAL 0.1 release

[David Zeuthen]

On Thu, 2003-10-09 at 22:52, Joe Shaw wrote:
> 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".
> 

I'm thinking this is a good idea; see below.

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

Yes, if there are any, see below.

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

I'm thinking that Token Ring, ATM, Ethernet etc. adapters (and maybe
even ADSL modems and PSTN modems) should share a common category,
"Network". 

So it maybe useful to have a sub category to specialize even further.
This is driven by the hardware parts.. It tells the libraries that
already support the device (libghoto) how to use it.

Now, I agree it's very useful to have a Capabilities property that says
how the desktop environment should treat the device. This should really
be driven by requirements from e.g. GNOME and KDE and should use
keywords such as "Audio Player", "PDA". It tells applications how to use
it.

So, I even think the capabilities part is so important that every device
must set it. Would you agree?

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

I thing both Seth and I (after Seth explained it to me) would beg to
differ ;-) See the "network connections" thread.

(Windows does this in various way I think, and it is confusing. On my
laptop at home the OpenVPN stack is a network adaptor (under Win2k that
I rarely boot) and on my laptop at work the SecuRemote VPN adaptor isn't
(also Win2k)).


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

The thing is that didn't want the Category to be a list.

> When (and why) would something be a "Camera" in Category but not be
> "Camera" in UserCategory?
> 

Oh, like never.. UserCategory was my failed attempt at trying to convey
the capabilities. I think having having a Capabilities property is much
nicer.

The downside is of course that we need to precisely document
capabilities in the spec ;-)

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

With capabilities you would add two more.

So, is this the way it would work:

1. Libraries would use category (or busclass) to interact with the
device; for camera libraries (e.g. libgphoto) they would find out
whether it's through usb-storage or through the user-space library using
libusb. Or, in the future, some other method...
  (this is why I want the category not to be a list)

2. Applications using said libraries would select the HalDevice* object
to pass to said libraries, by selecting on capabilities. The application
wouldn't really care how the said library does the magic. This would
future proof the applications for new busses.

3. This is not really much different in how existing libraries (like
libghoto) works today, it's basically just unification of information.


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

Excellent.

Thanks,
David