On 03/15/2012 11:30 AM, Jesse Cook wrote: >> At any rate, I don't have code to back this up, but it's certainly food >> for thought on whether it makes sense to try and enhance our use of RPC >> to support transactions without also having to add new public API. >> > > Your solution seems reasonable, though I'd have to really think about > it to see if there are any major holes in it. Could you leverage > compression to eliminate the need for a more sophisticated solution? Compression is indeed another option, but it still implies a new RPC, where if maxnames is <= limit, we call the old RPC, and if it is greater, then we call the new RPC which generates the list, compresses it to less than 256k (the rpc limit), and passes the compressed data as an opaque blob, then the client decompresses the blob to reconstruct the list. Simpler than having to do transactions, if you can assume the compression is always likely to work, but more complex in that we have to decide what form of compression to use. (All of this really boils down to a protocol contract between client and server, where both sides agree on how to represent data so that any one message is not disproportionately large). Back to my earlier comments about cross-compatibility, how a server must not reply with more data than an old client was expecting so as not to crash the old client, and therefore new clients must indicate that they are newer: adding a new RPC is indeed a form of feature negotiation (if you are new enough to call the new RPC, then you can deal with the larger return of the new RPC). -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list