[Kde-hardware-devel] Core Libraries

[Kevin Ottens]

Le Jeudi 5 Janvier 2006 17:41, Eric Gaumer a écrit :
> What will be the underlying code that Solid will use to manipulate network
> hardware?

Currently the primary target is not fixed. The first backend will surely be 
NetworkManager though, my only concern with it is that it's very limited...

> The reason I ask is because I'm currently working on creating a library
> based on iproute2. This would give applications the ability to perform
> direct operations on network hardware.
>
> My vision is a network daemon that unifies all aspects of network
> configuration across desktops as well as distributions. This would
> eliminate things like ifup/ifdown and even replace ip or ifconfig. The
> daemon would also be able to store network profiles internally across
> reboots.
>
> The actual daemon part comes into play by using the DBUS technology to push
> network events (i.e., new 802.11 network discovered or cable unplugged,
> etc...) out to applications that are "network aware".
>
> My vision is similar to RedHat's NetworkManager project but goes beyond
> that by providing a complete replacement for most, if not all, network
> start-up scripts and providing a uniform mechanism for any Linux desktop to
> build tools around.

Well, you're basically describing a NetworkManager on steroids. I'm not 
against seeing something like this emerge, but why aren't you sharing with 
them or trying to extend it in the first place?

Please note that I'm asking this to satisfy my curiosity, there's surely a lot 
of reasons to start from scratch, but that would be sad to duplicate efforts 
for the wrong reason. ;-)

Note that such a daemon would surely make my dreams come true (be it 
networkmanager improved or something completely different).

> My motivation is this; network management sucks on Linux. Sure if you like
> to hack you can always ease the burden but users like mom are completeting
> left hanging.
>
> I was very happy to see this project come along and I definitely think it's
> a step in the right direction.

Thank you.

> There isn't a whole lot of information given it's infancy so I'm not sure
> what the API will be built upon.

I don't want to set a choice in stone, hence why the current design has a 
frontend/backend split.
Since I'm currently focusing on hardware discovery, I provide a HAL backend, 
but it's perfectly feasible to have another backend for a competing solution 
or another platform. The backend just will have to provide the right 
interfaces. Also note that those interfaces are far from decided yet 
regarding network management, I'm clearly open to proposals in this area.

> I'd be interested in getting involved. I can program C/C++ and Python. Most
> of my work with the QT/KDE API has been with Python. I'd be more interested
> in the core libraries.
>
> Can anyone give some insight as to how the project plans to interact with
> network hardware and wether or not something like libiproute2.so would be
> helpful in achieving these goals?

Of course it would surely be helpful. I tend to think that the lib itself 
wouldn't be enough though. A lib+daemon combo like the one you described 
above looks very interesting.

> I have a crude working library just as a proof of concept. The iproute code
> uses some global variables that I'd need to clean up and I'd probably wrap
> some of the functions to provide a more consice API. Eventually the ip
> frontend would simply link to libiproute2 or disappear completely but the
> option handling is messy as it stands. I'd consider implementing a finite
> state machine to handle all the options available and provide a cleaner
> code base.

Just for further references, could you give us the necessary information to 
download the code of your library?

In order to have the whole picture of your work. Do you have any plan for 
dealing with ppp* connections, and VPN?

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060105/910e1af9/attachment.pgp