Re: [libvirt] [PATCH] Increased upper limit on lists of pool names
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)