On Tue, Mar 06, 2007 at 11:25:32AM +0000, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
I'm not sure what you mean by 'expose the remote interface directly' ? Do you mean allow arbitrary non-libvirt clients to speak to the server daemon directly, or something else ?
I've been wondering this morning what reasons clients would have for wanting to reverse-engineer/reimplement the wire protocol. If they're using an obscure language without libvirt support? (Answer: write some libvirt bindings, stupid!) If they're using an obscure language which lacks a C FFI? If they have license problems with libvirt?
Keeping C library based binding for a Java application is really annoying, and JNI is like designed to make this hard. I would expect large clusters monitoring solutions to be often Java based and we need to have a network API for those use case. Whether the Sun-RPC based one is the answer I don't think so, I guess they would be far better off with XML-RPC, in term of existing libraries, tools, and knowledge of programming the beast. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/