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

[Jeffrey Hutzelman]

--On Friday, February 11, 2011 10:17:40 PM +0000 Tom Keiser 
<tkeiser@sinenomine.net> wrote:

> I'm quite keen on removing the proprietary union-plus-opaque-default
> specification from my I-D in favor of this generic new union type.
> However, this leads to a question: would it be desirable to defer
> semantics (such as criticality) to the discriminator namespace
> definition in each I-D so that the base union I-D remains very simple
> and generic, or would it be better to split the discriminator
> namespace up into several regions along a few axes (e.g.,
> standards-track/experimental, critical/non-critical) right now?  I'm
> perfectly fine going either direction...

I don't think that's up to the primitive type.  Depending on the usage, 
there may well be no concept of critical types.  For example, an interface 
allowing a client to request a list of addresses for a fileserver has no 
need for critical address types.  Some clients of that interface should not 
proceed unless they understand all of the addresses; others need not worry 
about the ones they don't understand.  Criticality here is entirely in the 
eye of the application.



> Yep.  Adopting unions is going to complicate our job in
> significant--and sometimes subtle--ways.  For example, with
> non-idempotent RPCs that have union OUT params, you have the ability
> for remote state to be mutated, but for the caller to be incapable of
> decoding the results.  We're going to have to learn to be very careful
> about how we use this new union primitive...

Note that that's already true if you use union OUT parameters, or if an OUT 
parameter is a vector type and the server sends a result longer than the 
caller is willing to accept.  We should, of course, refrain from defining 
calls in which a server might trigger these cases.  However, the whole 
point of this exercise is to allow us to do things like allow a server to 
return data to a client which it might not be able to fully interpret. 
Naturally, as with any extensibility mechanism, we must be careful to 
specify appropriate behavior when unknown extensions are encountered.

Note that it's also possible for remote state to be mutated and the caller 
to not receive the results for any number of reasons, such as network 
failure.

-- Jeff