Request for comment: a new software to manage linux networking features

[namnd]

martin f krafft wrote:
> I think the strongest argument for netconf is that it tries to be as
> stateless as possible and that it is pretty much distro-independent.
> Moreover, it does not touch the kernel interfaces but leaves it up
> to scripts to do so, for ultimate flexibility.
>   
If you don't keep a lot of network states yourself, your software can't 
do many things useful, I hope that after some effort,  you will agree 
with me on this point.
> It's also aimed at replacing ifupdown, not overriding it.
>   
Many packages call ifup/ifdown or rely on /etc/network/ifup.d/*, if you 
don't provide all those features, other packages will break, people 
won't accept it.
>> Daemon based approach doesn't allow the system to boot in single mode.
>> It's a disadvantage, isn't it?
>>     
> Single-mode does not mean that all daemons have to stop.
>   
How people call it single mode when your daemon runs on background while 
the user is doing something on the shell?
>> netupdown, when installed, completely overrides ifupdown (ifup and
>> ifdown will be symlinks to netupdown). The usage syntax is
>> completely compatible so other scripts can continue calling
>> ifup/ifdown as is. If I want to remove ifupdown, it'll be an easy
>> job for netupdown.
>>     
> Interesting. Do netupdown has full compatibility of all
> /etc/network/interfaces options, including hooks and mappings?
>   
netupdown provides /sbin/ifup and /sbin/ifdown, but 
/etc/network/interfaces must be translated into /etc/network/config.xml 
format. With the comments here, I planned to support /e/n/i format so 
it'll be in the to-do list, and it's very easy to implement. Extracting 
information from a text file (in this case it's /e/n/i) is the core 
competency of Perl.
>> I believe that after the first prototype, you will need to rewrite
>> the  code at least once. It'll take you several work months before
>> people  start joining your project.
>>     
> Yes, I am aware of that. Unless I can get people like you interested
> earlier so that they help. Because I don't have very much time for
> netconf...
>   
I oppose the idea of relying on a daemon at the core, and I don't 
believe the "stateless" idea will won't, so I can not join the current 
netconf design.
>> Currently, netconf is too young, mostly an idea instead of
>> a product. I still recommend you to use the netupdown code base at
>> the starting point to start coding in C++, if you do so, I can
>> join your project.
>>     
> So you want me to throw away everything I've done so far and adopt
> your code under the netconf project name?
>   
You should not throw away anything useful, you should keep at least your 
dbus stuff if you are to adopt my code base, it's very good for desktop 
use, we may separate a core package, a package for server, and a package 
for desktop.