On Sat, Dec 18, 2010 at 11:19 PM, Tom Keiser <[email protected]> wrote: > On Dec 17, 2010 11:17 PM, "Matt W. Benjamin" <[email protected]> wrote: >> >> Hi Tom, >> >> I've read the tag-length-value draft specification multiple times quickly, >> and once carefully. Though I'm not expert in volser, the proposed protocol >> seems very coherent and reasonable. >> >> Though it's a nit, I find some of the long token constants (e.g., >> "VOLSERTAGUNSUPPORTEDENCODING") hard to read. It might be nice to break up >> the token namespace with understores (e.g., >> "VOLSER_TAG_UNSUPPORTED_ENCODING"), if the token length exceeds some minumum >> (14 characters seems plausible)? This is already done for most token >> namespaces in the draft. >> > > Sounds good. I'll make the necessary changes for draft -04. > >> I wondered also if the tag cache coherence ambiguity could be helped >> through the use of some type of data version or serialization token in >> relevant calls? >> > > Hmm. That's an interesting idea. Proposal: If we were to add an OUT > parameter to each Get...TLV RPC, which communicated the generation number > for the tag namespace, then--combined with rx epoch checks--the caller would > know when to re-fetch the list of available tags. > > Although I doubt this issue is likely to come up very often in the real > world, an additional four byte payload hardly seems objectionable... > > Does that sound reasonable and sufficient? If so, I can incorporate the > idea into draft -04... > > Thanks very much for the feedback.
That sounds like an excellent plan to me. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
