Hartmut Reuter wrote: > Jeffrey: > Is that the kind of specification you are looking for? Or what else?
I would like a specification of the entire protocol such that it is sufficient for me to be able to implement RXOSD support based solely on the specification. The specification must include not only the protocol messages but also a description of the required semantics. Only with such a specification will it be possible for independent developers to implement RXOSD. More importantly, only with such a specification is it possible for analysis to be done of the protocol to identify areas where it alters the existing AFS protocol semantics, or conflicts with other work that is in progress. The concerns that Tom Keiser raised are serious. One of them will be addressed via the use of Start/Extend/End messages for Fetch and Store operations. However, there are still open questions. What is the behavior when a client dies after sending a Start Store? Is there a rollback mechanism that the file server must use to restore the pre-existing data version? Does the file server assume that the data was written and increment the data version? These are decisions that will need to be made and I'm sure that there is not going to be consensus on what the answer should be. Also, any discussion regarding revisions to the afs3 protocol must take place on [email protected]. The [email protected] list is not read by the Arla and kAFS developers. You are implementing RXOSD for OpenAFS Unix CMs and servers. However, we must be inclusive of all AFS implementors in any protocol discussions. Thank you. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
