[142] in Athena User Interface
Re: Virtual lockers
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Thu Jun 8 00:51:56 2000
Message-Id: <200006080451.AAA14504@hikari-no-ken.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: Brad Thompson <yak@MIT.EDU>, aui@MIT.EDU, tibbetts@MIT.EDU
In-reply-to: Your message of "Wed, 07 Jun 2000 23:10:01 EDT."
<200006080310.XAA20913@No-Whammies.mit.edu>
Date: Thu, 08 Jun 2000 00:51:51 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>
On 6/7 you wrote:
> I call these lockers "virtual" because it seems to me, rather than
> dealing with all the overhead of actually setting up and attaching
> real lockers for each submenu, it would be more efficient to put all
> the relevent config files in one AUI-related locker. This would give
> some performance boost and code simplification, by only attaching one
> locker no matter how many submenus are wanted by the user. It would
> also probably be more convenient to administer, if there were ever any
> global changes the AUI maintainers needed to make. AFS directory ACLs
> could still allow trusted parties to control various partly
> overlapping pieces of the potential menu tree.
I disagree about convenience. I am imagining a system that understands
/mit/lockername/.gnome/applications which is not very hard to
implement. This means that we don't have to think about two different
abstractions. We can write tools that will work the same on both
"real" and "virtual" lockers. It means that users who delve below the
abstraction (its still Unix, at least some of them will expect to be
able to) will be as unconfused as possible.
I think that you overestimate the "overhead" of attaching a locker. It
is simply the creation of a symlink, not particularly hosing.
tibbetts
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
