;; short-prop.txt ;; -*- outline -*-
;;
;; short proposal for the REALM

	       REALM - REorganized Athena Locker Model

* description

  REALM would create a new set of general-purpose lockers, holding
  references (initally) to software available in other lockers.
  Initially, at least, a REALM locker would most likely be a type
  MULTI filsys entry, causing to be mounted all of the necessary
  specific filesystems.  Eventually, it should be possibly to migrate
  these lockers into the REALM locker itself, changing the sublocker
  filsys entry so that it instead mounted the correct REALM locker.

  A REALM locker would move the abstraction layer back from single
  packages to larger logical groups, making resource discovery simpler
  for users, and decreasing overhead required for ALM inter-locker
  dependancies.  A REALM locker would become the abstraction layer
  itself, as it could be maintained as references into completely
  seperate AFS volumes, for example.  Mirroring would be done by
  shadowing the REALM locker itself, replacing refererences to remote
  systems with local ones, allowing other systems to `fall back' to
  the remote system.  (tools would need to be developed to do this
  simply and efficiently).

* 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.

* work to be done to implement the REALM

  first, and perhaps the most difficult, would be to abstract the
  currently available software (and perhaps project) lockers usefully.

  After this is done, filsys entries would need to be created, and
  maintainers would need to be found.

  software for mirroring and determining correct filsys subscriptions
  and authentication would need to be developed.

** possible REALM divisions

*** math software
   xess, matlab, maple
*** text editing/document processing
   emacs, latex, frame
*** media 
   graphics, audio, video, etc.; viewing, manipulation
*** utility software
    
*** development
   gnu, compilers, interpreters
*** reference 
   dictionary, thesaurus, spelling checker, eb, 
*** communications
    netscape, irc, ytalk
    mail, ncftp, kermit
*** administration
   administrator tools
*** games
   games.  duh.

** problem
   databases
   how to deal with testing/beta software?