hal draft spec

David Zeuthen david at fubar.dk
Wed Sep 17 03:17:30 EEST 2003


On Sun, 2003-09-14 at 20:31, Jens Nordenbro wrote:
> Hi there!
> 
> I would like to know the relation beween the hal draft spec and supermount-ng 
> (http://supermount-ng.sourceforge.net/) 
> 
> Complement or competetion ?
> 

Hi, 

I suppose someone else could answer this better and shorter than myself,
but the way I see it, supermount-ng is a set of useful linux kernel
patches that, in a way, tries to solve a set of problems that I envision
that hal could _assist_ in solving in more desktop environment friendly
way.

To answer your question, I really see it as a complement. The long
answer is articulating my vision of the hal more clearly (idea with
views borrowed from the OpenGL spec):


  IMPLEMENTORS VIEW OF HAL: The HAL is a database of objects, called
  devices, with both well-defined and, for HAL at least, unknown
  properties (a property is simply a key/value pair).
  In addition, the HAL consist of a set of programs and libraries
  that access these properties in a well-defined way by performing
  well-defined actions under well-defined circumstances.

  The HAL, proper, has nothing to do at all with access to
  devices or the kernel.

However, assuming this point of view[1], and I really apologize for
being so abstract, at least the following components needs to be in
place for the hal to be useful:

 o  Hot plugging agents.
 o  Device probing
 o  Device configuration and booting
 o  Device usage

I don't envision these being part of HAL at all - that is, the former
three, I expect to be OS/distro specific and the latter to be device
category (think gphoto, cdrecord, CUPS) and desktop environment (think
configuring devices) specific. 
The latter could be extensions to existing libraries, the former could
be integration with the OS, specifically the supermount-ng stuff on
Linux.

What does this mean? It means that well-defined interfaces and
specifications needs to be in place since I assume parts of the
freedesktop.org mission is to support a variety of both OS and desktop
environments. 

And I very much believe that these requirements should be driven by
desktop environments in a desktop environment neutral way, hence this
list [2].

Or am I just rambling? :-) I mean, at the end of the day, being abstract
won't help or write code, so parts of me wants to do USB device proof of
concept integration with a desktop environment. But a proof of concept
demo is never going to evolve unless it is backed by a specification.
So, it's really a two-fold process...

Well, enough rambling for now :-)

Cheers,
David

[1] : and other views like those of libhal applications, desktop
      environments, OS vendors, device vendors should be 
      'agreed upon' or somehow specified or conveyed.

[2] : although one needs to get buy-in from all the layers of 
      players in the software stack. For the time being, I'm just hoping
      that they read the xdg-list ;-)





More information about the xdg mailing list