--On Friday, February 11, 2011 10:17:40 PM +0000 Tom Keiser
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
