[Kde-hardware-devel] Network Mangement

[Kevin Ottens]

Hello,

First of all, sorry for not keeping people on list informed, my schedule has 
been quite packed and I simply didn't manage to mail earlier. Basically what 
happened this week is that I committed the NetworkIface, AcAdapter and 
Battery capabilities. It means that the work on network and power management 
has begun.

Le Saturday 13 Mai 2006 12:54, Christopher Blauvelt a écrit :
> I hadn't updated my solid code in a while and last night I noticed
> that you had added the network device code.  It was similar to what I
> had written except that it contained less data in the structure.  I
> had also included:  the bus type, isWireless was getMedium which would
> return wired or wireless,

Right, that looks like a good idea to replace isWireless() with a medium() 
method (I don't like the get*() naming scheme much since it looks out of 
place in a Qt-like API) returning an enum value.

> and a function isPrimaryDevice for the 
> purposes of determining which device will be the default gateway.
> My thoughts were to have each network device contain a "Network"
> class. 

That's my main point for disagreement with your proposal. I don't think we 
should get the Network objects directly from the devices returned by the 
hardware discovery layer.
Since this disagreement is linked to the last paragraph of your mail, I'm 
copying it here:
> Additionally, where should we store class interfaces that aren't
> necessarily devices.  A network isn't a device and would be possibly
> confusing having it in with the rest of the devices.  On the other
> hand, it may just be a special case and get put in with the rest of
> the devices.  I can't think of any other instances within this project
> that we'll be handling something that isn't actually, "hardware."

With network management you have real network interfaces (as given by the 
hardware discovery) and virtual network interfaces (think about VPN for 
example). That clearly can't fit in the hardware discovery layer.

I think that Phonon has similar concerns, it'll both have to handle real and 
virtual sound input and output. Hence why I don't think we're really facing a  
special case here.

We have to find a general pattern to handle this cases, and it's clearly 
enough for trying to avoid mixing the hardware discovery with other concerns 
as much as possible. Sometimes it won't be the case, but network management 
is complex enough by itself to be separated.

My plan regarding this, is:
1) to keep the hardware discovery as it is working now, not providing more 
services (detecting devices, querying the device list, providing capability 
interfaces to gather data from the device in a portable way).
2) for each domain (network management, power management, sound... which means 
that Phonon would fit in this plan), to keep the necessary classes in their 
own namespaces and providing a frontend/backend decoupling
3) for the corresponding capability interfaces and domain classes, to provide 
bridges to make the "joint"

To illustrate this I think we'll have something like a class 
KDEHW::Network::Interface which provides a method to find the right 
KDEHW::Device it's bound to if it's not virtual. Of course, the given 
KDEHW::Device would see its is<KDEHW::NetworkIface>() method return true. I 
think it'll also be possible to introduce the symmetrical method in 
KDEHW::NetworkIface.

Please note that I'm not quite happy with the class naming scheme in this 
short example... It seems that It'll require some work to get it right.

> This would give data such as: IPv(4|6) address, subnetmask, 
> broadcast, Rx bytes, Tx Bytes, errors.  If the device was wireless it
> would also contain information about: SSID, encryption type, Tx Power,
> sensitivity, etc.  Basically all the information you'd get out of
> 'iwconfig eth0.'

Now back on the principle for interfaces describing networks, I'm all for it 
(if they're kept in their own namespace as described above). Two remarks for 
designing the solution though:
1) We should keep the frontend/backend separation in mind. I don't want to 
close the door to the people wanting to port on other platforms.
2) From your description I would introduce a WirelessNetwork interface 
inheriting from the Network interface and having the wireless specific 
methods.

Now I'll comment on the proposed methods themselves.

> On the network device structure I believe we should have the following
> functions:
> QList <Qstring> getIPv4Info() const;
> QList <Qstring> getIPv6Info() const;

Could you be a bit more specific about what those methods would return? A list 
doesn't hold a very clear semantic to me.

> bool isPrimaryDevice() const;
>
> //Wireless specific
> ProtocolType getProtocol() const;

hm, what about returning a ProtocolTypes flag set? I'm thinking about network 
supporting both wifi B ang G here, I don't know if it's worth it though.

> QString getSSID() const;
> EncryptionType getEncryption() const;
> EncryptionKey getEncKey() const;
> int getSignalStrength(bool inDBM=true) const;

Could you make the parameter a bit more explicit? In particular I think we 
should use an enum and not a bool here. Moreover, inDBM doesn't really ring a 
bell to me. =)

> QString getSignalStrength() const;

What is the difference with the previous method?

> int getSensitivity() const;
>
> //in enum.h
> enum ProtocolType { WifiA, WifiB, WifiG, WifiN, BlueTooth, ZigBee };
> enum EncryptionType { WEP, WPA, WPA2 };

Maybe WPA(2) Personal and WPE(2) Enterprise should be separated?

> EncryptionKey would have the following functions:
> QString keyAsHex()
> QString keyAsDec()
>
> Later we can add some "setxyz" functions but I'm focusing mainly on
> getting information right now.  What are your thoughts?

Yeah, I don't know if we need a really complex EncryptionKey type. We could 
keep it like this and see if more needs arise.

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: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060513/c2dce4c7/attachment.pgp