On Fri, May 17, 2013 at 08:04:30PM +0200, Peter V. Saveliev wrote: > On 05/17/2013 07:06 PM, Daniel P. Berrange wrote: > > <skip /> > > The idea of handing off this to an external python daemon isn't > > really very appealing to me, because I don't really like libvirt > > core functionality depending on anything python related. > > > > Really libvirt should just talk network directly rather than > > invoking the 'tc' command, or there could be a low level C > > library that could be used instead of 'tc'. I don't think we > > need to hand this off to a daemon at all. > > Does it matter, in what the language is written the external program, > when it follows some standard API? Having once C implementation, that > meets the requirements («no python»), one can always replace python > implementation. Since there can be more appliances for such traffic > controlling application, than only libvirt, standard API will make it > possible to reuse it in other solutions — be it python implementation, C > or even erlang. > > Python was choosen 'cause of one simple reason: it allows to implement > netlink message encoder/decoder a way much easier than C, and since the > netlink control message communication doesn't require high throughput, > python's performance more than enough. Simple structure handling in > python allows in this case really fast time-to-market features delivery, > sometimes it makes sense. Beside of that, some high-level virtualization > solutions uses python anyway, so mostly this application will not even > create unique package dependencies, using only python stdlib and no > tricks like ctypes and so on. > > But as I said, the language in this case really doesn't mean so much, > having standard RPC API. C — ok, maybe someone will implement it in C > also. The key issue is to have the API standard. Yes, the choice language *today* does matter, because it impacts on the minimum install base size possible with libvirt. It also impacts on operational aspects becasue python is not a low footprint runtime from a memory POV, and not OOM friendly. As per my previous mail I also think this kind of higher level interface to netlink should be a C library rather than an RPC system. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list