[AFS3-std] Re: PTS authentication name mapping draft, second call for review

[Jeffrey Hutzelman]

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 
<simon@sxw.org.uk> 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