[Kde-hardware-devel] Name Resolution (The non domain kind)

[Kevin Ottens]

Le mercredi 9 août 2006 06:15, Christopher Blauvelt a écrit :
> After looking through Wil's patch there are a couple things that make
> it diffiicult to merge given the changes that I've made off of Kevin's
> guidance.  In summary these changes were:
> - Remove the Net namespace and directory, putting everything in the
> solid base directory.

Yes noticed this one too late. See the patch I sent a few minutes ago, it 
solves this. I just hope you didn't go through the same path than me to get a 
clean patch...

> - change wifi to wifinetwork (not really a problem just here for the
> sake of completion)

We'll stick to the WirelessNetwork name (as in the patch).

> - only have one singleton

Which is currently missing from the patch I sent, hope to get it as soon as 
Will is back (I think he made a few modifications on it since the last time 
you posted your archive on list).

> As such I have done the following:
> - Removed the Net namespace and replaced all mention of Wifi with
> WifiNetwork
> - Removed the NetworkManager class and only have the 
> TCPIPManager

I'm a bit split on the name... We probably want to 
s/TCPIPManager/NetworkManager/ everywhere, and make the backend able to 
report which kind of networks it handles (tcp/ip, x10, etc.). This way 
nothing stops us from having different backends for different network types, 
and make the frontend class able to load several backends at once (unlike the 
DeviceManager)

> class.  This is the only singleton and serves as the front-end API
> - Removed the "Net" directory and put everything in Solid
> - Merged the two enums.h files (as a consequence of removing the Net
> directory)
> - Removed multiple inheritance (it wasn't really needed anyway) 

Well, except for the Solid::Ifaces::Enums classes.

> Kevin, you told me that once I made these change we would have to
> choose our class names carefully, well you were right :)  The main
> problem comes from Will's inclusion of a class called device, which
> you may remember is already taken by the hardware manager.  I think
> that many of the functions in the device class should be done in the
> TCPIPNetwork, as I think they are pretty much one and the same,
> otherwise a "network" is a pretty abstract thing that wouldn't need to
> exist.  It seems more that what the device class was referring to was
> the interface more than the device itself.

I agree that "NetworkDevice" (I named it this way for now) is probably not the 
final name we want. But having the Network + NetworkDevice split is what we 
want because you can't mix the network interface and its current settings, 
that's definitely not a good idea.

As for the naming we probably want NetworkDevice to be names NetworkIface. And 
the current NetworkIface should be renamed to something different, 
NetworkCap(ability) maybe? I'm not sure I like this name (it would mean to 
rename AudioIface too for consistency).

> So it seems more appropriate to call the what is now the NetworkIface
> class the NetworkDevice class since everything in that class is device
> specific.

See my comment above. I'm reluctant to name it NetworkDevice since the way we 
built the model it's not really a device but a capability on a device.

> I like the idea of having Encryption be it's only class.

Yeah me too. =)

> It opens up 
> the possibility of having a lot more options without crowding the
> TCPIPNetwork class.

That's exactly the point. That also means that we'll be able to be more future 
proof regarding encryption schemes.

> Finally with the patch, it seems as though the 
> frontend is being designed around NM as opposed to being more generic
> (I say that from looking at the enums included in
> Net::Ifaces::Enums::Device)  would it be possible to move more of that
> stuff into the backend?

Yes that's definitely what we want to do. Currently there's really the 
Capability enum from WirelessNetwork that looks too backend specific, and it 
can probably be solved thanks to the Encryption class anyway. So I'd say it's 
easily solvable.

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/20060809/67d464cb/attachment.pgp