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 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 ); Network networkType<class Solid::Capability>(); signals void networkDeviceAdded( const QString &net ); void networkDeviceRemoved( const QString &net ); 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 virtual bool isVirtualNetwork() const = 0;//is this a VPN? virtual QList<QString> statistics() const = 0;//this list will change for different network types virtual NetworkIface* networkDevice() const = 0;//the associated network device virtual QString net() const = 0;//similar to udi 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. 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. _______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel