[patch] remove wireless support

[Owen Fraser-Green]

Hi,

On Fri, 2004-06-04 at 02:20, Nick Penwarden wrote:
> Owen Fraser-Green wrote:
> 
> >3) When I'm at other customers I use no network.
> >4) When I'm at home I use a wireless network with the ESSID "Discobabe"
> >5) When I'm at a friends house I connect to a wireless network with the
> >ESSID "x5".
> >
> This is why it makes sense to leave in the wireless capabilities on 
> wireless cards. With this information a higher level program could check 
> the net.ethernet.link status of all ethernet cards and use those if 
> appropriate. If not, it could use iwlib to scan for and check ESSID's of 
> all access points found by any card marked with the wireless capability. 
> That would be enough to satisfy your above scenarios I should think.
> 
> -Nick

OK, so maybe I'm splitting hairs but if it's really going to change
profiles on-the-fly then to distinguish between 3), 4) and 5), it's
going to have to poll iwlib continuously, which is what I think HAL
should help to avoid.

Concerning the use of iwlib/whatever-HAL-enabled-lib, a big downside (at
least for me because I really hate doing any coding in C anymore) is
that of language bindings, as I already mentioned in a previous post. If
the convenience of bypassing root access is considered a laudable goal
then I think the convenience of making things readily available which
were only previous available through some (or the reality until someone
is bothered to write all these class-specific libraries: many different
ones depending on platform) C library is also worthy. As a mono user I
think it's fantastic to be able to get all this device information so
easily. The use case I was discussing here; why not write it in python.
Yes, it could have been done before - lot's of .NET/python bindings for
all sorts of libraries but who's bothered to maintain them all? HAL
provides a small, static information to what can be dynamic database of
information underneath.

Another slight problem I have with the whole class-specific library
thing altogether incidentally is distribution bloat. Every new library
means yet another .rpm/.deb/.tgz/.ebuild. Also, supposing, as I predict,
that runtime-based programming becomes much more popular and, for the
time being, the obvious choice is unclear, so we have the python
bindings, the mono bindings, the java bindings etc. to maintain as well.
No, I'm not advocating property writing again or any kind of hardcore
device manipulation, just that if HAL can provide all the most common
information, it leaves only a very small set of applications which
actually need to use iwlib. Leave this small handful to be written in C.
Then, seeing as it's such a minority, they can do their own abstraction
of the various platform-dependent toolkits and we do away with the need
for yet more libraries.

OK, now I'm rambling. I promise I'll let this thing drop soon :)

Cheers,
Owen


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