HAL 0.1 release
joe at ximian.com
Fri Oct 10 01:22:20 EEST 2003
On Thu, 2003-10-09 at 17:48, David Zeuthen wrote:
> 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.
I'm still not sure whether you need "Category". From 10,000 feet, a
camera is a camera is a camera, and a lot of the things you do to a
camera ("import photos") are the same regardless of bustype, etc.
But at some point you get down to a level (hopefully a specific library,
like libgphoto or whatever) that needs to know about hardware details
anyway. At that point, the library can get the necessary properties,
like busclass, /dev location, call other libs like libusb, etc. and do
the heavy lifting.
But to the app itself, all it cares about are capabilities.
The bottom line is, I don't think we can make "Category" be both general
enough to be useful on its own (that is, not just another capability),
but specific enough to contain enough information for low level
(Maybe we should set up a HAL mailing list? I think we might be
flooding xdg-list at this point)
More information about the xdg