[Kde-hardware-devel] Network Manager interfaces

[Kevin Ottens]

Hi,

First of all, sorry for the delay.

Le Mercredi 24 Mai 2006 19:45, Christopher Blauvelt a écrit :
> While designing the network manager I defined a network as any type of
> computer-to-computer communication.  This includes TCP/IP and IrDA,
> and later Bluetooth, X10, and One-wire.

I'm wondering if you're not trying to solve too many problems at once. Note 
that I'm not saying it's bad, just that maybe it'll make the task more 
difficult. So the question is, do we really want to add so many difficulties 
when most networking these days is IP based?

In your list I'm wondering about Bluetooth and IrDA. I'm not expert, but I'd 
tend to consider them as buses for devices (like using a serial port, or 
USB), not for networking.

> I have designed the API to 
> have a network manager class with the following functions:
>
> NetworkList allNetworks();
> bool networkExists( const QString &net );
> Network findNetwork( const QString &net );

That looks sensible for managing networks.

> Network networkType<class Solid::Capability>();

What's the use of this method? Using Solid::Capability there looks wrong...

> signals
> void networkDeviceAdded( const QString &net );
> void networkDeviceRemoved( const QString &net );

Looks ok. Maybe s/net/name/ should apply there as well?

> The network class will have the following methods:
> virtual QString networkAddress() const = 0;
> virtual bool isDefaultGateway() const = 0; //if this network is the
> default gateway for the device
> virtual MediumType mediumType() const = 0; //wired or wireless
> virtual CommunicationslType protocolType() const = 0;//ethernet, wifi, ppp

Are both needed? If protocol type is wifi I guess medium is wireless, isn't 
it?

> virtual bool isVirtualNetwork() const = 0;//is this a VPN?
> virtual QList<QString> statistics() const = 0;//this list will change
> for different network types

Which kind of "statistics" is it supposed to provide? Maybe returning a 
QVariantMap would be better? I'm definitely guessing here since the semantic 
of this method is a bit fuzzy.

> virtual NetworkIface* networkDevice() const = 0;//the associated network
> device

I would return a Device instance here. Of course is<Solid::NetworkIface>() 
should return true on the said device.

> virtual QString net() const = 0;//similar to udi 

Ah ok... that's what I tend to rename "name" earlier. If that's really an 
identifier it should be somehow noticiable from the name. It should be 
renamed IMHO (and my previous point about "clashes" is moot in this case).

> For each network type there is a class that inherits from Network.
> Classes such as tcpipnetwork, IrDA, and X10 will inherit from the
> network class.  tcpipnetwork covers all network types such as
> ethernet, wifi, ppp, nullmodem, etc.

Ok, so please enlighten me, what would be the use for IrDA, X10, etc.?

As for having simply a TcpIpNetwork class inheriting from Network that looks a 
bit like a limitation to me. AFAIK, ethernet, wifi or ppp convey different 
information and it would surely be better to have them in more specialized 
interfaces (WifiNetwork would have essid for example, and the cyphering type 
wep, wpa, etc.).

Now, we're still missing some features from your proposal IMHO. In particular 
we want to be able to activate or deactivate a network, make it the default 
gateway, changes its settings (dhcp, static), etc. so we'll have to think 
about it too.

> It is unreasonable to expect one backend to handle all of these
> network types.  To rectify this I designed network manager to use
> multiple backends.  If some functionality is not desired the "null"
> backend can be used which serves as a placeholder.  I expect this to
> cause some controversy however I don't see any other way to implement
> this functionality.

Once again I'm wondering if we really want such a feature. If we decide we 
want it, then having several backends in the network manager at once makes 
sense to me.

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/20060601/6470c005/attachment.pgp