I've not yet read Derrick's writeup, though I really should do so soon. However, I wanted to comment on this one point...
--On Monday, January 04, 2010 09:10:15 PM +0000 Simon Wilkinson <[email protected]> wrote:
> 8.3. GetCapabilities RPC > It is proposed that the first 32 bits be allocated to capabilities flags, while the remainder be reserved for future standardisation. I'm a little nervous about what happens to the remaining 195 bytes here - in particular if they end up being used for adhoc marshalled structures. But I guess that's a point that can be argued during "future standardisation"
At this point, we've added this operation to several other RPC interfaces already, and I expect this one to work the same as the others. So, not much discussion should be required here, at least for the moment. I would expect any future changes to apply to all GetCapabilities interfaces, rather than specifically to this one.
I would note that there are not "195 remaining bytes". The argument in question is a counted vector of afs_uint32, with a maximum length of 196 objects. We chose a vector because it only uses space in memory and on the wire for the number of objects actually used, and afs_uint32 because it is easily represented as a native type on all platforms and because any smaller type would still be transferred as a 32-bit integer, wasting space on the wire (this makes char arrays _extremely_ inefficient). I'm afraid I don't know anything about why the limit is 196 in particular. However, it's worth noting that this limit can be increased in a backward-compatible manner, if we're careful about it (in retrospect, I wonder if we shouldn't have given GetCapabilities an argument indicating the maximum number of words the caller is prepared to expect in the reply).
IIRC, the reason to talk only about the first 32-bit word is because we haven't settled on whether additional words should be treated as a simple extension of the bitmask or as some more complex sparse representation of supported capabilities. At some point, we'll have to settle this for all GetCapabilities interfaces.
-- Jeff _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
