On 06/06/2017 05:17 PM, Peter wrote: > On 06/06/2017 08:11 AM, Peter Krempa wrote: >> On Tue, Jun 06, 2017 at 07:45:10 -0700, Peter wrote: >>> On 05/26/2017 02:11 AM, Martin Kletzander wrote: >>>> On Thu, May 25, 2017 at 10:16:26AM -0700, Peter Volpe wrote: >> >> [...] >> >>>> If we standardize even the smallest part of the RPC, then it might >>>> screw >>>> us immediately. We are keeping it private just so we can enhance the >>>> APIs we already have. We don't know when we will need to change some >>>> part of it. >>>> >>> >>> How does the current ssh implementation work? >>> (https://libvirt.org/remote.html) If clients are able to talk to a >>> remote >>> libvirtd via ssh then there must be some sort of compatibility >>> guarantee. >>> Otherwise unless the versions are exactly the same clients wouldn't >>> be able >>> to talk to remote daemons. >> >> They use the internal RPC protocol transported over SSH. The client >> library initializes the ssh connection to the server, and then starts to >> talk the RPC tunelled over the SSH session. >> >> The compatibility is guaranteed only if you use the client library. As >> said, the RPC protocol is considered an internal detail and the client >> library shields you from a possible incompatibility if we'd ever make >> incompatible change. >> > > How does the client or server handle differing versions between them, > when the protocol changes? Or is it that client.x.x can only talk to > servers with the same exact version? So far there's just one version of the protocol. We try very hard not to break it or not to introduce a new one. And frankly, we haven't really had to so far. But in general, we preserve backward compatibility therefore if we ever introduce new version of the protocol, the old one is going nowhere so that older clients can use it. But then again, this is highly hypothetical. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
