HAL 0.1 release
Bryan W. Headley
bwheadley at earthlink.net
Sat Oct 11 17:05:21 EEST 2003
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'  attached with multiple interfaces will appear
> as a single HalDevice object. For example USB speakers will have
> "Capabilitiy = HID, Speaker"
> 4. 'Physical device'  (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' . 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)?
>  : 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  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.
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
More information about the xdg