On Wed, 7 Nov 2012, Andrew Deason wrote:

On Wed, 07 Nov 2012 11:43:15 -0500
Jeffrey Hutzelman <[email protected]> wrote:

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

I see valid arguments both pro- and anti- a generic CombinedTokens, and haven't had much time to think about it this week since I'm at the IETF meeting. It does seem, though, that the app-defined behavior is restricted to the server, since the client treats tokens as opaque and just passes them from server to server. It is probably possible to have an application client that knows it wants to combine identities but does not need to care about the details of how the identities are combined.

-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization

Reply via email to