> But refusing to do something with a given field because someone > somewhere *might* be using it is just silly. With that kind of logic, > we'd have to avoid ever changing because the change might be > incompatible with someone else's change. > > Let's have the groups we know of come forward, and lets put out a > reasonable number of public requests for others as-yet-unknown to do > so. If someone is hacking the source code and protocols at that level > and is not on *any* of the afs lists, well, they lose.
I concur. This strikes me as a good set of reasons to explicitly rev the on disk format and reserve any open areas as reserved for future use. If you stick things in unused/undocumented areas in widely used control blocks/disk areas, you should be prepared to adapt to future changes on your own. That's been the deal for as long as I've ever seen, and I don't see what makes this any different. _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
