[patch] remove wireless support

[Owen Fraser-Green]

Hi,


On Wed, 2004-06-02 at 00:35, Robert Love wrote:
> Let me lay out my thinking a bit on the reading vs. writing issue.  What
> it basically boils down to is that the system _needs_ iwlib _anyway_, so
> why duplicate stuff in HAL?

No, the Linux system needs iwlib but what about all the other operating
systems that HAL could (and hopefully one day, will) run on? In my
opinion, one of the most important features of HAL is it's potential to
be platform independent. Thinking at least along lines of GNOME which
strives to work across a variety of platforms, one of the main things
holding back desktop development when it relates to hardware is that
each program needs to link to a different library depending on the
platform it's running on. If the only dependency for a little applet
which pops a window every time a new wireless network is discovered is
d-bus bindings then suddenly the bar has been lowered considerably.

> iwlib can, theoretically anyway, provide a better interface for
> wireless-specific manipulation, anyhow.  

Surely pretty much everything HAL does could theoretically be done much
better using dedicated libraries for each of those tasks. Another
important feature of HAL though is it's potential to provide nearly
everything under one roof. It's an easy interface to use and it's got a
great bang:buck ratio. OK, so maybe it doesn't always afford the most
flexible interface (abstraction never does) but I'd guess at least half
of the programs which use the hardware directly today don't really do an
awful lot with it. I.e. they could be easily ported over to using HAL.
I'd also go further to say that there would probably be a lot more
programs which could have benefited from being able to discover hardware
properties if only something like HAL were there for them.

Along with platform independence, a similar issue is language
independence. Without meaning to brag, I reckon I could knock together
some C# in my lunch break which implements the aforementioned wireless
network discovery applet using HAL, hal-sharp and dbus-sharp.
Easy-peasy! No wait, I think I'll use python instead. No problem! In
actual fact I'm far too hungry to forgo my lunch break but the point is
that anything abstracted by HAL can be used via C, python and .NET. I'm
kind of a mono fan at the moment but, while attempting to write a fairly
big application in mono recently, I've already had to write dbus-sharp,
hal-sharp, gst-sharp, cddb-sharp, cdio-sharp (the latter can be done
away with if my optical disc tracks patch is accepted BTW :). Please
don't make me write wireless-tools-sharp too ;)

> Sure, it can use HAL for device
> discovery and such, but let's look at the code if we use HAL for reading
> the attributes but not writing.  We end up with two code paths.  One
> that uses the ioctl() interface to set a bunch of parameters.  Another
> that uses HAL to read a bunch of parameters.  Plus a conversion layer to
> convert HAL properties to the format that the ioctl's want.  At this
> point, there is really no reason to use HAL (aside from device
> discovery).  It is just dumb, in fact.

I agree the two code path thing is odd but I think a better goal is to
strengthen HAL to provide the missing second one instead of crippling it
by not providing any.

> OK OK, so you raise a valid point about some things that want to read
> but that don't need to write.  I can buy this, but to that I respond:
> why not just use iwlib?
> 
> My measuring stick is still "is it a setting or an inherent property of
> the device".

I use the same stick except my interpretation is "is it a [setting or an
inherent property of the device]?" :)

Cheers,
Owen


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