On Fri, Feb 11, 2011 at 5:31 PM, Matt W. Benjamin <[email protected]> wrote: > Hi, > ----- "Andrew Deason" <[email protected]> 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. The potential impact of dropping an XCB depends on the message > (esp. as it evolves). All but one of the original XCBs are effectively > breaks. The 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
