[patch] wireless patch, take 2

[David Zeuthen]

On Thu, 2004-05-27 at 16:46 -0400, Robert Love wrote:
> On Thu, 2004-05-27 at 22:26 +0200, David Zeuthen wrote:
> 
> > representing which one of .network0, .network1, ... we are connected to.
> > This one we could just write to. I mean, should you be allowed to select
> > a network that isn't in the list? 
> 
> Yes, I think you should, because one may just have their home ESSID hard
> coded in their network config files.  They should be able to set it and
> run with it, I think.
> 
> HAL should not implement policy - if the user wants to set their driver
> to a not-yet-in-range ESSID, let 'em.
> 

Nice catch, you're right, I didn't think of that, sorry. 

The thing is that I do think the HAL should offer some kind of
manipulation of the hardware, hence the API suggestion. It seems like a
nice way to offer this through setting properties but I'm not completely
sure how it would work. Hence, why I'd like to see some discussion of
the wireless network usecase which may be one of the more complicated
ones.

Remember, for reading information we also have what I've called
conditions that complement properties, e.g. a HalDevice can emit a
DeviceCondition. This is used for things that not easily expressible in
properties such as "this volume was unmounted" (implemented) or
"processor is overheating" (not yet implemented).

It seems whether we use properties or an org.freedesktop.Hal.Device like
API to manipulate a device is largely implementation detail to me, but
the latter approach does offer a lot more flexibility.

Cheers,
David



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