--On Tuesday, May 06, 2008 11:57:38 AM -0400 Matt Benjamin
<[EMAIL PROTECTED]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
