Progress, and another idea

[David Zeuthen]

On Tue, 2004-11-23 at 12:05 +0000, Hughes R Mr (UG - Electronic Eng)
wrote:
> 
> I’m glad that HAL’s permissions and other issues are
> being talked about, the model looks fantastic, and
> makes HAL much more useful as an abstraction.
>
> >              +------------------------+
> >              |          hald          |
> >              +------------------------+
> >               |            |         |
> >               |            |         |
> >         +----------+  +---------+   +-------------+
> >         | callouts |  | methods |   |  volume_id  |
> >         +----------+  +---------+   +-------------+
> 
> I understand HAL need to be compatible with debian
> (with groups) and slackware (non-SELinux) and
> because I’m *way* out of my depth with what is
> needed to be done, I’ll probably just comment every
> now and then, and try to submit the odd little patch.
> 

Sounds good.

> While I was installing my girlfriends laptop with FC3
> (not o/t, keep reading :-) ) I installed her printer,
> a Epson Photo 810. We needed to know how much ink it
> had left, and for the life of me I couldn’t find a
> way to show her. I ended up compiling and installing
> epsutil, but this is non-ideal – and as she was
> playing with solitaire I began to think – could the
> ink level be linked in with HAL? Wouldn’t it be the
> best place to put the monitoring? Then with DBUS we
> could query the information and not have to do
> application specific polling of a random
> /dev/usb/lp0 device.
> 
> How would I start to implement this? Are there any
> examples I can use, or tips you guys can give me?
> 

(a short repost of what I posted to fedora-devel to get other hal
readers up to speed)

I do think that hal is the right way to expose the API since the object
model representing hardware in hal is pretty much designed to export a
lot of different information (see hal-device-manager).

The code for polling for e.g. Epson printers, XYZ printers or whatever
shouldn't be a part of the hal codebase proper as it's pretty specific
to certain hardware. However there are ways to start other daemons from
the hal daemon (e.g. callouts when the hal daemon is starting up). 

The key thing is that such software populate the same device properties
on the hal device object representing the printer, and of course that
said properties are well documented and generic enough to represent a
wide range of different hardware. I guess that really entails sitting
down and studying the vast amount of various printers to get an
overview. This can be coupled with exporting e.g.
printer.epson.some_nonstandard_property.

So, one way to approach this is to write a program, ideally using
existing software for extracting ink levels, and make it use libhal. You
would then use hal_set_property() and friends to populate properties.
This program would probably run as a daemon and, ideally, it's lifecycle
would be controlled through callouts when printers are added/removed
(e.g. an Epson printer polling program shouldn't run if I don't have an
Epson printer). You would then be able to package this program and it
could be distributed independently of HAL.

In fact (in a blue sky future), once we settle a the right API (e.g. hal
properties to export), printer manufacturers could supply their own
programs along with the printer.

Also, all of this information isn't much useful without an UI - another
key thing is to integrate this into the various desktop printing stacks;
for GNOME that could be eggcups, but I could be wrong (IIRC the GNOME
printing stack is currently being reworked).

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal