On Wed, 07 Nov 2012 11:43:15 -0500 Jeffrey Hutzelman <[email protected]> wrote:
> > There are elements of CombineTokens that are not application > > specific - the way we generate the combined key, the limits on > > lifetime, bytelife and expiration time. I don't think so. > In fact, really the only application-specific behavior is the > combining of identities. Yes, but how you combine identities dictates how the whole thing works. So, for example, in AFS we have one way of combining tokens, for the CM and user tokens. For that case, you want the combined expiration time to be the lesser of the expiration times of the input tokens, right? Say I have another application, where I want to combine tokens such that the combined token means "try the given operation with identity0, then try with identity1 if that fails", or something like that. I would think that the expiration time of the combined token would then not be the lesser of the input tokens. Since, even if one of the input tokens would have expired, the other may be usable, and in such a combination scheme, you don't need both input tokens to be valid at the same time. No? > I'd rather not see the generic operation go away just because one > component of one application chooses for convenience to do the same > thing in an RPC that also does two other things. More generally, > while AFS is certainly a driving force for Rx, as someone who has > written a number of other Rx-based applications, I think there is > great value in maintaining the notion that Rx is its own protocol with > AFS as one application, rather than just some of the common bits of > the various AFS protocols with no concept of layering or abstraction. Sure. What I'm saying is, any application, AFS or not, needs to define what this RPC means; it's not usable on its own. So, if you have this generic RPC that is used by different applications, I see two annoyances/issues: 1. You have the same RPC with the same name, code point, and arguments, which does potentially very different things. That could be confusing. 2. Each application needs to specify the behavior of the CombineTokens RPC for that application anyway. And if you need to add any input or output arguments, you need to make an entirely new RPC. So trying to define an application-agnostic one seems like it might be a waste of time. It just doesn't seem like reasoning about the details of the result of "combining tokens" is meaningful, when "combining tokens" is intentionally undefined and could be _anything_. This doesn't seem worth the time spent on it, though. I'm just trying to explain what I mean; if people just plain disagree, I won't push it. If nobody else wants to go in this direction, I'm fine enough with any of the suggested additional text from Ben/Simon/me on this. (The "the new identity is an application-specific combination [...]" stuff.) -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
