[patch] remove wireless support

[David Zeuthen]

On Thu, Jun 03, 2004 at 01:56:01PM +0200, Kay Sievers wrote:
> On Thu, Jun 03, 2004 at 11:07:57AM +0200, Owen Fraser-Green wrote:
> > Hi,
> > 
> > On Wed, 2004-06-02 at 17:25, Robert Love wrote:
> > > Yup, and this will undoubtedly lead to the need to have other libraries
> > > built on top of HAL (and, really, it makes sense to have a class-
> > > specific library on top of HAL).  And once there is a lib on top of HAL,
> > > the abstraction might as well be there.
> > 
> > Let's say there are four levels of abstraction:
> > 
> > 1) The inherent properties of the physical device
> > 2) The properties that the operating systems uses to address the device
> > 3) Device settings
> > 4) Actually using the device for its intended purpose
> > 
> > Now, HAL clearly already tries to do 1) and 2) and everyone's happy
> > about. I think we're also in agreement that abstracting 4) is pretty
> > silly and I'm definitely not advocating that. 3), though, is the grey
> > area and, really, this wireless properties thing isn't the only time
> > it's been stepped into. Hard drive volumes, I believe fall into this
> > category, for example (it's a UNIXism to view them as devices). So does
> > ethernet MAC address and rate. By applying the setting vs. inherent
> > property yardstick then why not get rid of these too?
> 
> I don't think, the border should not be the physical hardware. Volumes
> are independend devices, regardless of their place on the system.
> I think HAL should do device discovery only to the point the device is
> classifiable and it can create a unique identifier(udi) to store
> system(fdi), user(capability attributes) and config values for this
> device.
> HAL should also be able to merge the system/user device data if the same
> device is discovered in a different location or if more than one
> identical device is discovered. MAC adresses, serial numbers or volume
> labels are great for this job.
> HALs polling for media changes falls into device discovery, only the
> polling for the network link state is now a grey area.
> 

This is a very good description of the scope of HAL, I really like it,
thanks. Any properties not falling within this should be _carefully_
examined and discussed before being added. This is not to say they
shouldn't be added; I rambled about the convenience of having them and
so has Owen. And I don't think this means we need to add writable
properties, if the app is that complex it'd better use a dedicated
library to interact with the device.

We shouldn't underestimate whether something is convenient or not,
after all I think we all agree that one of the major goals is to make
it easy to use devices. And especially if the information we want to
export is just a pain to get from a unprivileged app running in a
desktop session, let's provide it then. And if it can save us from
having to run Yet Another Daemon to just check for this property (like
network link state), let's discuss whether it should be included or
not. For something like wireless networking, that might just hurt us
more because it would be a pain to support it since we'd have to do
all kinds of tricks to avoid the burst of callouts and message
emissions. So, the cost of having this, already, debatable set of
properties greatly offset the benefits. So, Robert, please apply your
patch to remove it.

> If we want a OS independend interface for wireless networks, someone may
> define a api for it and make a new abstraction library, that uses hal to
> discover the devices and possibly reads HAL config values, and provide the
> glue between the systems lib and the new abstraction library.
> This way applications can use this new library to be OS independent and
> HAL doesn't bloat with APIs for all possible classes of devices.
> 

This was the idea all along, as I wrote in another mail. And, hell,
many libraries exist today, let's just go and integrate them with HAL.

> Maybe the the _name_ HAL is the really misleading thing here?
> Hey, we can call it "City of Devices" :)
> 

It is misleading, at best. DeviceKit is a much nicer name, don't you
think?

Hope this helps, Thanks,
David

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