;; prop.txt ;; -*- outline -*-
;;
;; proposal for the REorganized Athena Locek Model

	       REALM - REorganized Athena Locker Model

* purpose 

  The purpose of this document is to address a number of difficulties in
  the existing `athena locker model' (ALM).  The position of this
  document is that the locker abstratction is a good one, but that the
  ALM lacks certain management guidelines that could improve the ALM as
  a whole.
  
  The two key objectives of the REALM are:
  
   o improved accessibility of locker-provided resources to end users
  
   o simple, low-pain intergration with the existing system

* description of current ALM

  In the ALM, a locker is a logical subset of the filsystem, organized
  in some fashion.  In practice, every user has a locker (yandros,
  kretch), many courses have a locker (6.170, 10.001), many projects
  have a locker (pismere, cwis), and many software packages have a
  locker (gnu, sipb, emacs).  In this context, `a locker' means `at
  least one locker).

  This document is concerned primarily with what I call `software
  package lockers'; locker which exist primarily to provide software
  to people in general, and which do not currently have an
  organizational scheme.  Course and user lockers have an external
  organizational scheme.  Project lockers may or may not be best
  included with the course and user lockers, or with the software
  package lockers.  REALM can be seen as an attempt to define an
  organizational scheme for software package lockers.

  One important feature lacking in the ALM is a global discovery
  mechanism for lockers.  This was seen as desireable in a system
  where there was no distinction between user lockers and software
  package lockers.  This ability was cobbled loosely from discuss
  meetings, mailing lists, FAQs, and word of mouth; a situation which
  will never be wholly removed.

  Another large problem with the ALM is that shared libraries do not
  work well within the ALM; programs linked with shared libraries
  either must require that the library locker be attached, or that the
  abstraction provided by the locker must be avoided, adding a
  silent dependancy on a system maintained by an unknowing other.

* description of non-locker solution

  One possible solution to this problem is to simply avoid using the
  locker mechanism, instead relying on the global availability of the
  filesystem.  This technique can be simpler, but removing the
  abstraction completely complicates filsys subscriptions and, for
  AFS, cell authentication.  Additionally, AFS paths tend to be quite
  long, much longer than the matching locker mountpoint paths that are
  used in the ALM.

* improved accessibility from the REALM

  REALM is an attempt to add an organizational framework to software
  package lockers.  The particular structure is intended to provide a
  simpler interface to users, reduce the number of lockers that are
  typically attached, and still provide the location-independance
  functions associated with lockers today.  Specifically, some means
  to retain filesystem-independance is necessary.

  In the ALM, the organizational group is conceptually very small,
  which allows great flexibility on the part of the user; the subset
  of the filesystem that can be addressed as a separate unit is quite
  precise.  The idea behind REALM is that this highly detailed view of
  the filesystem is optimized towards locker maintainers, not users.
  REALM would replace this view with a much more generic addressing
  scheme, based on general access areas.  For example, rather than
  having lockers for emacs, emacs19, xemacs, frame, and ez, REALM
  would perhaps have an `editors' locker.

  The small organizational unit of the ALM allows the maintainer great
  flexibility, but the resulting complexity is passed to the user;
  users must somehow discover the correct set of lockers for complex
  systems, which often results in a large number of lockers to be
  added.  This adds time to login (for example, see the dialup process
  statistics on `attach') and can cause problems for shells which have
  some arbitrary limit on the length of the execution path.

  By consolodating many of the existing lockers into a more general
  structure, many `hidden' and `silent' dependancies can by made
  overt, and thus dependacy compatibility problems can be addressed.
  The more general locker structure makes resource discovery much
  simpler (shifting the efforts from the isolated user to the
  relatively well-informed maintainers).  The smaller number of
  executable path entries makes path management simpler and reduces
  the chances of exceding the path length limit.

* simple, easy migration to the REALM

  REALM can be done as a complete superset of the ALM, for as long as
  is desired, and is opt-in.  Minimal resource expenditure is required
  (hesiod entries, maintainer time, development of tools to ease
  maintenance and mirroring).

  This is accomplished by having REALM lockers added next to the
  existing locker system, at least initially.  A REALM locker would be
  maintained by a group of 

* disadvantages of the REALM

  Filsys alert subscriptions might become complicated.

  Managing multiple versions of software can be somewhat
  complicated. (The fine-grained control of the ALM allows for
  indirection through the locker mountpoint, across versions.  Some
  experience with the lockers for X, motif, emacs, and sipb have
  implied that this practice tends to confuse users.  Additionally,
  the multi-version availability of some third-party packages might
  become complicated.  The current indirection methods used, however,
  would apparently work equally well under either system.

  Some amount of programmer time is necessary, for creating the tools
  necessary for managing the REALM lockers in a way that can be easily
  mirrored.