Matt Benjamin wrote:
The devil is in the details. While the XG might be beneficial to help you solidify your thoughts, I recommend that you focus on the English description of each message exchange and how it will be used.Based on comments made in the previous round of discussion, which seems now to have died down, I'd like to suggest an interface for further discussion.The intention is not to innovate beyond the ideas for which there appeared to be consensus (supporting snippet included). Thanks to Tom Kaiser, for initial check-over and comments. Thanks, Matt
I do have two technical comments:
1. I think the file server should be able to cancel the callback
contract as part of the delivery of any event.
2. The AFSCB_Event_XXX messages that you list parallel the RPCs made
to the file server by clients. However, they do not necessarily
describe the notifications that need to be sent to the receiver of
the callback. An RXAFS_RemoveFile RPC effects two objects, the
directory that contains the entry and the file that was removed.
At present there are two callbacks that are sent. One for each
object. I think there needs to be two different messages there.
One describing the change to the directory object and the other
describing the removal of the file. Note that removal of the file
is going to be a message that cancels the callback contract since
the file will no longer exist.
Spending the time to produce an Internet Draft style document will make
it a lot easier to determine what has been missed. The XG can be an
appendix to that document but it cannot be a replacement for it.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
