Scope and Using devices
David Zeuthen
david at fubar.dk
Fri May 28 13:40:31 PDT 2004
On Fri, 2004-05-28 at 16:21 -0400, Joe Shaw wrote:
> > I think Owen has another good point in that IP is software. And if we
> > start putting all sorts of software properties onto devices it smells
> > like policy.
>
> Smells kind of fishy to me... I mean, I guess it's *technically*
> software, but it's something I usually consider a property of the
> hardware.
>
Robert wasn't wrong when he said you can be persuasive :-)
Ok, let's say we implement this, and all devices expose a lot of
properties with configuration variables and these are gettable and
settable. This includes networking devices, block devices (for the
label), storage devices, sound devices and maybe modems. Hmm.. can't
think of more devices.
So, using HAL it would be really easy for a desktop capplet in GNOME or
KDE to set the IP address or change the wireless network. What about
setting the route?
But wouldn't this conflict with a lot of the network configuration
already present in OS? But wait, the OS vendor could hook in with
callouts in property.d and reconfigure the files.. Hmm..
> (FWIW, I see issues in setting the IP address as far as conflicting with
> things like DHCP or ZeroConf, but really those issues aren't any
> different from any application which would otherwise set the IP address
> on its own.)
>
Continuing our assumption that we want properties for IP addresses and
so forth I'd like to note that using an proper method based API instead
of just a setter-API would allow a method SelectDHCP() on the interface
org.freedesktop.Hal.Net.
(and note that writing only .Net and not .Net.Ethernet
or .Net.Ethernet.80211 is _not_ a typo)
> > Well, HAL shouldn't care about sound,volume since that really a software
> > thing.
>
> I guess. This is another thing I associate more with hardware than with
> software.
>
Ok.
> > 1. What kind of properties should HAL expose. I say, let's keep to
> > hardware and the configuration of hardware. And thus I argue that
> > scanning for wireless networking is actually in the realm of hardware
> > configuration. Thus we should really provide a way to change that. Same
> > with volume labels. It's the right thing to do.
>
> Yeah, I see where you're coming from, but today as an application
> developer there's not really any difference between getting the ESSID
> and getting the IP address. In both cases you open a socket and issue
> an ioctl() on it. Why provide that information in some cases and not
> others? I suspect it's similar for both volume labels and the volume on
> the sound card.
>
Robert wasn't wrong when he said you can be persuasive :-)
> > 2. Whether the properties should be set via SetProperty or via an API. I
> > have argued for the latter but do note I'm cool with the former. I just
> > see some issues doing that.
>
> Yeah, same here, but the other way around. :)
>
I still believe a proper method-based API is _the_ way to go.
Bad analogy time: Think of the HalDevice as a car: the properties are
the dashboard, think about the Rounds Per Minute of the engine as
car.rounds_per_minute, and the brake is the method Car.Brake(). You
don't manually turn the needle on the dashboard to reduce the RPM's
right? :-)
(ok, so it was a bad analogy, couldn't resist, sorry :-)
I'm very curious about what other people think about this - Robert
wasn't wrong when he said you can be persuasive :-)
Cheers,
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list