Scope and Using devices

[Joe Shaw]

Hi,

Promise not to be mad. :)

On Fri, 2004-05-28 at 22:40 +0200, David Zeuthen wrote:
> Robert wasn't wrong when he said you can be persuasive :-)

I think I may have completely flip-flopped on this.

Robert brought up a great point on Friday.  I don't remember if it was
on-list or in person, but he asked, "If you didn't need to be root to do
wireless scanning, would you have bothered adding it to HAL?"  The
answer is definitely not.  If root weren't required, there is already a
library there which would have gotten the job done just fine.  Apps
could have used HAL and that library in tandem to change wireless
settings, etc.

Based on your email I got a couple hackers together here at Ximian and
tried to present the problem to them.  At first there was very much the
feeling that HAL should try to abstract away as much access to the
device as possible.  But as we talked about it a bit more, there was
some retreat from this, but the one large issue that remained is access
control.

The thing is, HAL will never be able to do device access as well or as
flexibly as a library could.  "Do one thing and do it well", etc., etc.
These libraries mostly already exist today: iwlib, libgphoto, etc.  In a
lot of cases applications can use these along with HAL today, and
hopefully these libraries will be adapted to use HAL intrinsically in
the future.  Oh, and libraries can (and perhaps should) do policy,
whereas HAL probably shouldn't.  It's having all that infrastructure in
hald, resident in memory, probably isn't the best approach.

It doesn't make much sense to me to do things like bridge properties
between HAL and CUPS when really the best API for this is (ahem, at
least in theory) CUPS's own.

So what we were thinking is that SetProperty would exist basically as it
does today: a means for callouts to set properties as necessary, but
that it'd have no real effect on the daemon's operation.  The properties
would be basic details about the device: not settings.  Things like
PCI/USB product, MAC address, network interfaces and device nodes,
storage drive types, volume filesystem types would all still be there.
Things like wireless properties wouldn't.  Things like volume labels and
UUIDs fall into a gray area for me.  Maybe they should be omitted too.

The core problem of access control still exists, but really that problem
exists no matter what.  If we want to do setting, we can probably either
implement our own (I've done it for Red Carpet, so I'm starting to get
good at it. ;) or reuse dbus's.  But I'd rather see it fixed somehow in
the operating system, maybe using POSIX capabilities.  But I hope that
Robert will be able to answer more to that than I could. :)

Joe


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