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

[Tom Keiser]

On Fri, Feb 11, 2011 at 5:31 PM, Matt W. Benjamin <matt@linuxbox.com> wrote=
:
> Hi,
> ----- "Andrew Deason" <adeason@sinenomine.net> wrote:
>
>> But in that situation with XCB, if you get an unknown callback type,
>> there's not anything you can do with it, so the only thing I can see
>> happening is that you drop it. And so, you've dropped a callback
>> break,
>> which means losing information or keeping stale data around in the
>> cache.
>
> Maybe, yes. =A0The potential impact of dropping an XCB depends on the mes=
sage (esp. as it evolves). =A0All but one of the original XCBs are effectiv=
ely breaks. =A0The current flock XCB interface is a bit different, etc.
>

This brings up an important point that we had to address in
draft-tkeiser-afs3-volser-tlv--namely, that the encoding peer
sometimes needed to flag an arm as "critical".  We did this by adding
a bit field with a "critical" bit, which told the decoding peer that
failure to decode the arm must result in a failure of the call,
whereas lack of this bit left error handling up to the decoder (e.g.
the decoder could choose to ignore the failure).

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 would expect that the fileserver be told that a client
>> doesn't
>> understand a certain callback type, and so would have to work around
>> it
>> (probably by sending a Cancelled or something).
>
> Yes, there is a need that type of information, possibly at both ends.
>

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...

Cheers,

-Tom