[AFS3-std] extended callback cancellation, please discuss

[Jeffrey Hutzelman]

--On Tuesday, May 06, 2008 11:57:38 AM -0400 Matt Benjamin 
<matt@linuxbox.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> There has been some IRC discussion about cancellation in extended
> callbacks, between myself and Jeff Altman so far.

And there's been previous discussion on this mailing list, and both public 
and private zephyr conversations.  At this point, there's a lot of material 
for people to try to review and understand, and much of it isn't available 
to everyone who might be interested.  Note that because this is a public 
forum, "everyone who might be interested" is a larger set than "everyone 
you've already talked to about it", and potentially much larger.  That, and 
the presence of easily accessible, persistent archives, is why it's usually 
preferable to have discussion on an open mailing list rather than in a 
number of more private venues, often all at once.

I think at this point that we've had sufficient discussion that it is 
appropriate to begin putting together a concrete, self-contained proposal 
which does not depend on prior mail or other conversations.  Jeff and I may 
be a bit biased in this respect, but we've both found that a good way to 
have a semi-stable reference point for discussion which can be evaluated 
equally well by everyone is to write up a proposal in the form of an 
internet-draft.  I would strongly suggest that you do so in this case.

Such a document would not just be an xg, but would explain the purpose and 
semantics of each operation and code, situations when servers are or are 
not expected to issue different kinds of notifications and how the client 
is expected to react (personal preference: please read RFC2119 and use its 
terminology).  I do think that for an AFS RPC protocol or extension, it is 
appropriate to include a partial xg file, since that is what defines what 
the messages look like on the wire.

-----

Now, I'll go ahead and add a couple of my own comments on the approaches I 
see being described, which you may want to take into account when preparing 
your draft.  First, I would note that we already _have_ a separate message 
for the case when all the fileserver wants to do is indicate that it will 
no longer guarantee that a vnode will remain unchanged.  That is 
RXAFSCB_Callback().  However, I can think of two cases in which a 
fileserver might want to cancel notification without using that call:

(a) When there has been no change, but the fileserver wants to disclaim
    any responsibility for reporting future change.  In theory, an
    RXAFSCB_Callback call should be sufficient for this case, since
    clients should respond to such a call only by marking cached state
    as invalid and not by immediately fetching new status, but some
    clients may do the latter.

(b) When there has been a change, and the fileserver is issuing a detailed
    notification (in which case RXAFSCB_Callback is _not_ called), but
    also wishes to disclaim responsibility for future notifications.
    The idea here is to avoid two round trips when one will do.


I think we can have further discussion on this question, but that it would 
help a lot to have a concrete proposal.


-- Jeff