[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Remote patch, 2007-02-28



Daniel P. Berrange wrote:
On Mon, Mar 05, 2007 at 09:49:42AM +0000, Mark McLoughlin wrote:
On Thu, 2007-03-01 at 13:56 +0000, Richard W.M. Jones wrote:
Do you have some actual concrete problems with SunRPC? For me it solves the problem of marshalling complicated data structures, including all the error infrastructure, over the wire (see src/remote_rpc.x). It is very trim and efficient. It demonstrably allows us to run over TLS, Unix domain sockets, and ssh. It handles versioning for us.

On the other hand, coding with it is grotty to say the least.

But we definitely shouldn't publish the SunRPC interface or allow others to interoperate with it, so that we can keep our options open in future.
	So, thoughts on the SunRPC stuff:

- IMHO, we're never going to encourage people to use the SunRPC interface directly, but at some point we may really want to expose the remote interface directly and so we'll move to another
    transport.

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?

My overriding concern is that we don't release anything until we're
confident we can support it long term without breaking compatability
with future releases. ie at very least old clients should always be
able to talk to new servers. Arguably new clients ought to be able to
talk to old servers too - albeit with possibly reduced functionality.

That clearly means we need stability in the wire format from day-1.
That puts some constraints on our internal API - but it is still
internal so it could be re-written completely if desired, provided
we keep wire format.  API efficiency feels like one of those issues
we can evolve over time - if we have a wire format that lets us do
versioning, we can add new RPC calls at will without breaking old
ones.

So far, the release model for libvirt (correct me if I'm wrong) has been that you periodically bundle up the latest version of libvirt and put it on the website. There's no experimental branch where we can place things like a libvirt remote patch with the proviso that at some point later we can say "sorry, that didn't work". Apart from CVS of course but even there it seems that once a patch is committed the libvirt maintainers aim to support it forever.

Rich.

--
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421
 "[Negative numbers] darken the very whole doctrines of the equations
 and make dark of the things which are in their nature excessively
 obvious and simple" (Francis Maseres FRS, mathematician, 1759)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]