HAL 0.1 release

[David Zeuthen]

On Sat, 2003-10-11 at 00:14, Havoc Pennington wrote:
> Another option is for each device to have:
>  Interfaces = Modem, HayesModem, Network, Disableable, PCIDevice
> 

Ok, this is what is discussed in another part of the thread only with
the word "Interfaces" being replaced by "Capabilities" (in plural to
indicate it's a list).

To move on, trying to conclude, can we all agree that

 1. Capabilities (I'd rather use this word, "Interface" is quite over-
    loaded) is a list of keywords that is not (necessarily) derived from
    the hardware but must be provided in device info files. 

    It is always required and cannot be empty.

 2. We need to define each keyword appearing in Capabilities in the
    HAL spec. At the end of the day, it's really two things:

    a) up to what libs/apps we use, to handle this, e.g. libraries
       advertise they can handle devices with a set of Capabilities.

       For instance the netprofile work as outlined by Seth might
       search for capability "Networking", while a modem dialer
       library might search for "HayesModem". libghoto might handle
       "Camera" and Rhythmbox might handle "AudioPlayer"...

    b) Hints to the desktop environment 'what the devices does', not
       'what it is'

    I don't think we neccesarily need to think in terms of
    inheritance. And I think we can grow the list of capabilities
    over time as we get more support. So apps/libs would pull in
    new capabilities and other required properties as time goes.

 3. 'Physical device' [1] attached with multiple interfaces will appear
    as a single HalDevice object. For example USB speakers will have
    "Capabilitiy = HID, Speaker"

 4. 'Physical device' [1] (like the printer Bryan mentioned) with
    multiple device-level objects each with a single interface
    will appear as many HalDevice objects.

 5. We require the PrimaryCapability property to be set to convey
    the primary usage of the 'Physical device' [1]. This can be 
    used to look up an icon using the icon-theme-spec

    We could also use the first capability mentioned as the 'primary
    capability'; either way works for me.


If we can agree on this, I'll merge this into a version 0.2-work-in
-progress of the spec.

ps. : I like the Disableable capability!

[1] : Using just 'device' is not sufficient in this thread. What I mean
      is really 'the expensive new box with many buttons and other
      geeky stuff that you attach to your system'

> And each interface in the list implies that specific properties will be
> present. There would then be no separate "device category", to get all
> cameras you just check for devices that support camera operations. 
> On the down side, maybe sometimes you'd have empty interfaces existing
> just so you can see if the device is_a particular sort of thing.
> 

> BTW, for the icon problem - I'd expect devices to have an Icon property,
> returning an icon name to be looked up using the icon theme spec.
> 

Thinking that this should be optional, I'd rather use the fact that the
capabilities list is ordered. Also the console tools for hal, such as
lshal, won't show icons!

Cheers,
David