[6091] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Greg Price)
Wed Dec 3 13:43:31 2008
Date: Wed, 3 Dec 2008 13:38:16 -0500
From: Greg Price <price@MIT.EDU>
To: Evan Broder <broder@mit.edu>
Cc: release-team@mit.edu, athena10@mit.edu
Message-ID: <20081203183815.GX10836@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4936C0EC.5080304@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Wed, Dec 03, 2008 at 12:25:00PM -0500, Evan Broder wrote:
> Under this scheme, attach and detach still call liblocker, but only to
> create or alter attachtab entries; they don't operate on the filesystem
> at all.
The new semantics of /mit, that Debathena has always had, is
(*) /mit/<foo> links to the <foo> locker as identified in Hesiod.
It would be very sad to lose this. If detach, which is widely
documented, started working again then we would lose this.
The reason liblocker hasn't been updated already is that it doesn't
really have a role in this world. Why don't we just let it die?
We do need some form of attach -e, for people maintaining replicated
lockers. I don't think this needs to be any more complicated than
making PyHesiodFS accept the symlink() call and accept unlink() on
symlinks. That plan allows people to make fudges on the semantics (*)
but only very consciously. It's also of minimal complexity.
Greg
