[Libvir] Remote patch, 2007-02-28

[Richard W.M. Jones]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070306/96518b2c/attachment-0001.bin>