netconf and python

[martin f krafft]

also sprach David MacKinnon <blaedd at google.com> [2007.09.19.0915 +0100]:
> So.. Hijacking the thread a bit. I understand why some people want
> netconf written in C (debian-base), but I also worry that the
> people most likely to want to contribute to netconf, won't, once
> it's in C, and that the project will stagnate thereafter.

If you look at the code right now, you'll notice strong resemblance
to C already. If ported to C, it would be object-oriented in the way
Python is, by passing structs as argument #1. It *is* possible to
write readable and maintainable code in C... it *is* possible to
write Python-like code in C. Since I have a strong interest in
keeping my sanity, that's the path I'd take.

Also, another thing to keep in mind is that only netconfd, the core,
will be reimplemented in C. All the methods, those things actually
interacting with the operating system, can be anything, including
shell scripts.

> Unless you intend to have a mechanism for plugins to be written in
> arbitrary languages.

So, yeah...



also sprach Colin Alston <colin at thusa.co.za> [2007.09.19.0926 +0100]:
> I personaly don't see any benefit in rewriting netconf in C. I'm pro 
> it entering a rewrite phase after prototyping, but there is no reason 
> it can't remain Python based.

The problem is with dependencies. If netconf is to enter Debian base
or run on an embedded system, you can't require Python.



also sprach Colin Alston <colin at thusa.co.za> [2007.09.19.0958 +0100]:
> Thinking specificaly on Debian, Python is already a dependency for
> the base system last I checked.

I don't think so. Maybe python-minimal, but that's not enough to run
netconf.



also sprach David MacKinnon <blaedd at google.com> [2007.09.19.1014 +0100]:
> > Right, but that also means you can't import any (fancy^Wuseful)
> > module which is not int the minimal python.
> 
> You have pretty much the same limitations in terms of C libraries
> though.

The C libs in any base system provide everything netconf needs:
subprocesses, threads, sockets, dynload, ...



also sprach David MacKinnon <blaedd at google.com> [2007.09.19.0943 +0100]:
> Certainly that sucks for embedded devices with limited memory. Are
> they going to be a common target for netconf though? (Serious
> question)

Not primarily, no.



Trust me, I have no particular interest to code C. However, I know
of many administrators who despise Python with a vengeance, and
a lot of these happen to be in Debian's development team. I *want*
netconf to replace netbase/ifupdown. I want it to become *the*
network configuration management system for Debian, then other
distributions. Sticking to the lowest common denominator is going to
be a requisite for this.

Now, I actually wouldn't be opposed to the idea of keeping the
Python implementation around for people to hack with, and porting
new, proven stuff to the C implementation. I am not sure whether
this is possible, but it would be something to keep in mind.



Anyway, David, you seem to be concerned that people won't contribute
anymore once netconf is reimplemented in C. Well, that's a valid
thought and concern and all, but right now there aren't any people
contributing while it's in Python, so unless that changes, your
argument is literally zeroised. :)

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"if you have built castles in the air, your work need not be lost;
 that is where they should be. now put the foundations under them."
                                                -- henry david thoreau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20070919/c8e6030a/attachment-0001.pgp