[6094] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Bill Cattey)
Wed Dec 3 14:10:20 2008
From: Bill Cattey <wdc@MIT.EDU>
To: Greg Price <price@mit.edu>
Cc: Evan Broder <broder@mit.edu>, release-team@mit.edu, athena10@mit.edu
In-Reply-To: <20081203183815.GX10836@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Wed, 03 Dec 2008 14:09:54 -0500
Message-Id: <1228331394.14797.3.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Score: 0.00
Am I understanding correctly here?
You want to maintain the debathena semantic compatibility that the
detach command does nothing?
This can't be right. That would mean that a disabling of the detach
command implemented as a particular artifact of the evolving debathena
interface would then drive an INcompatibility with the long-standing
semantics of detach going back to Athena on Vax.
Can you please clarify?
-Bill
On Wed, 2008-12-03 at 13:38 -0500, Greg Price wrote:
> 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
