On Thu, 10 Mar 2011 14:03:18 -0500 Tom Keiser <[email protected]> wrote:
> _We're_ explicitly not trusting the discriminant: we're assuring > generality by leaving that decision up to the error-handling semantics > of the specific union type definition. All we're doing in this draft > is making a best effort to continue decoding the stream--so that the > RPC framework has the _ability_ to defer error handling to the > upper-layer, rather than having to fail the entire call with prejudice > within the RPC layer itself. Fine. I just don't see how any application can sanely look at any data after an arm with an unexpected length. Anything after that is effectively garbage, and so if it succeeds in decoding, it can very well be line noise or other data that happens to be decodable as a union arm or other elements in the struct (or RPC arguments). When this occurs, _something_ has violated the definitions agreed upon a priori, so I cannot see how any subsequent data is ever interpretable. I don't see how any application-specific knowledge changes any of that. But still, erring on that side is obviously preferable to the alternative. If we allow flexibility that is never utilized, I guess that's not really a problem. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
