[AFS3-std] Re: XCB union decoding (was Re: Encoding IPvN addresses)

[Andrew Deason]

On Fri, 11 Feb 2011 14:34:56 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> I think extensible unions are a good fit for XCB, because of the bulk
> delivery mechanism.  But yes, you'd need a way for the client to
> indicate to the fileserver which of the XCB entries it understood, and
> perhaps to return a per-entry error code, in the same way that
> RXAFS_BulkStatus does.

I had thought that what callback types the client understands would be
handled at a higher layer, like capability bits. And if you accidentally
send the client a type they don't understand, you've got a serious
divergence of what you think the client is, and should renegotiate the
client capabilities (or even the entire callback state).

But that's just one way. I could see the XCB messages using an
extensible union, but relying on that to have the client tell you what
callback types it doesn't understand is problematic. If you send the
client a callback of type X, and the client says it doesn't understand
type X, do you just not send callback type X... forever? If the client
gets upgraded to understand callback type X, you don't have a way to
know when to start sending them again, unless you rely on capability
negotiation. In which case, well, the caps should tell you what the
client understands on its own.

On the other hand... I suppose if you use an extensible union, you may
get more information about which specific callback caused the error,
which could be helpful for debugging and such. So, maybe there's a win
there.

-- 
Andrew Deason
adeason@sinenomine.net