[6110] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Thu Dec 4 12:51:18 2008
Date: Thu, 4 Dec 2008 12:50:34 -0500 (EST)
From: ghudson@MIT.EDU
Message-Id: <200812041750.mB4HoYAt008314@outgoing.mit.edu>
To: Ken Raeburn <raeburn@mit.edu>
CC: release-team@mit.edu, athena10@mit.edu
In-reply-to: <B0FFD4AC-5517-46FC-8AD3-BD37518C5904@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
> It's probably reasonable, but it is a functional change that should
> be considered carefully.
A bit of perspective here:
Athena 9.4 has a lot of machinery in it which allows you to do
particular things in particular ways. This is good for continuity for
past users of Athena 9.3, 9.2, 8.x, etc.. but it is also cumbersome
and costly to maintain.
The major vision of Athena 10 is to allow people to do almost all of
the things you can do in 9.4, but not necessarily in the same way if
it's costly to make that work. Compatibility is a design goal but not
an overridding one.
I don't think there is any compelling reason to support lockers which
mount in /mit/foo for values of foo other than the locker name. It's
not compatible with the new auto-mounter approach (since there is no
reverse map) and it is not the common usage. There may be isolated
exceptional cases, but in the long term it is probably better to
address the exceptional cases than to continue to provide the
machinery.
