On Thu, Sep 27, 2012 at 3:06 PM, <[email protected]> wrote: > head at the moment), maybe we should think about this.... what about > asking IBM about their current feelings? It's not clear below whether IBM's > professed desire for backwards compatibility is 12-years old, or current. >
It sounded like active discussion with IBM to me, so likely to be fairly current. Also, IBM has this thing about supporting their customers... those that are using AFS will likely want to continue doing so and require backward compatibility (and likely only a small subset will be that interested in new features, at least initially). > Or to maintain backward compatibility, can we fork a new CM and set of > server procs on different ports that provides the new oft-wished-for > features while allowing older CMs to talk to older server procs on the > original ports. And have both I imagine this offers the potential for confusion, although it might be possible. But see below; many of the same concerns apply. (Byte range locking is a good example of protocol changes that can't sanely be protocol-invisible to older clients.) > use the same on-disk data? (ala kerberos4 and kerberos5, etc.) There are > probably a million reasons that won't work, Same on-disk data is not going to fly; new on-disk data will almost certainly be needed for most if not all of the features people want to see. And putting it "beside" the existing data may not work if (a) that data needs to account for older clients (b) needs to account for older *servers* (older dbservers in particular). -- brandon s allbery [email protected] wandering unix systems administrator (available) (412) 475-9364 vm/sms
