On Mon, 22 Jun 2009 00:28:48 -0400 Derrick Brashear <[email protected]> wrote:
> Backwards compatibility should not be a barrier to deploying new > RPCs. It should be a barrier to allowing the addition space to be > used in environments which do not wish to break said compatibility. > The least common denominator should not be allowed to hold back sites > wanting or needing more. > > For sites that cannot change clients, disallowing consumption of IDs > beyond the current limit is an easy answer. If I want to use more, > and am willing to, for my site, do the upgrades or make some volumes > unusable to old clients, I don't see why I should be restrained from > doing so. This was my intention when submitting this. I did not have a plan or scheme in mind for backwards compatibility; if a site wants to support legacy clients, I imagined they would simply not use volume IDs above the 32-bit barrier. Implementations would/should have some kind of administrative switch that administrators would explicitly have to turn on to enable them. I'd also like to note that the simple 32->64 conversion isn't the only way to do this. I've been told there's at least one other proposal in the works for extending the volume ID-space which conflicts with what I wrote. I'll see if I can help get it on this list soon. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
