HAL 0.1 release

[Bryan W. Headley]

David Zeuthen wrote:
> 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!

What other 'ables' do we have -- hotpluggable, readdressible (things 
given a dynamic IP from dhcp; that may not be it's address tomorrow)?

> 
> [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'

Yes, I like it.

What you called footnote [1] I tried to convey as "that gray, 
printer-looking box over there", which is really a physical location or 
a bus endpoint, but that's all.

Watch out for libraries advertising "Networking", unless they have 
sub-stratas saying "Ethernet", or "IPV4/IPV6", "UDP", "SNMTP". Although 
it's true that AppleTalk, DECNet and TokenRing have long been fading 
away... You never know what's next.

Havoc,

Interfaces is extremely vague. In 'Network' and 'PCIBus' I see the 
topography in which we can address the 'iron' (another synomyn!). It's a 
modem, so we should deal with it using a modem interface; it's a Hayes, 
so we should use the ATDT command string interface when dialing.

As opposed to, it's a Modem (inside its box is something that has Modem 
Capabilities), Type HayesModem (e.g, has Hayes command set) ?

What's an Interface? An API, or it's addressibility?

-- 
____               .:.                 ____
Bryan W. Headley - bwheadley at earthlink.net