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

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 ?

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.