[56] in DCNS Development
Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (akajerry@ATHENA.MIT.EDU)
Mon Jul 8 14:28:01 1991
From: akajerry@ATHENA.MIT.EDU
Date: Mon, 8 Jul 91 14:25:20 -0400
To: jon@MIT.EDU
Cc: dks@MIT.EDU, Raeburn@MIT.EDU.akajerry@ATHENA.MIT.EDU, mar@MIT.EDU,
In-Reply-To: Jon A. Rochlis's message of Fri, 05 Jul 91 19:53:30 BST <9107052353.AA12454@delwin>
> I believe the argument is (and has been for years) that SIPB is not
> Athena and Athena is not MIT. The "traditional" place to mount new
> project type filesystems is under /usr so there is /usr/sipb,
> /usr/athena etc. SIPB does not presume that everybody using the SIPB
> locker will be using Athena and therefore the sipb locker should not
> be mounted under /usr/athena or /mit (wich is an Athena-ism) ...
This raises the point of how we support different kinds of
software providers in generally. The current thinking is that there
are five types of software providers: the Operating System vendor,
Athena, locally acquired third party vendors, centrally acquired third
parte software, and third party software providers/distributers.
The OS vendor clearly sets the ground rules, things have to
fit into their setup. We assume that the workstation owner already
has decided to run the OS vendors software. The workstation owner can
also pruchase third party software to be installed and run on his
workstation, this I refer to as locally acquired third party software.
Athena is an optional addition to the base OS that allows for
interaction with the Athena Computing Environment. In addition Athena
provides centrally acquired third party software.
The third party software providers/distributers is software
provided through remote filesystems. This is well established as the
Athena-ism of lockers, but there is certainly no reason why Athena is
required in order to use the locker abstraction. The locker idea
provides a unique interface; it allows just about anyone to provide
software to the general community, with the least amount of work on
the part of the provider. No packaging is required for locker
software, it's just there and you get it through a single mount point.
SIPB is a third party software provider/distributer; it can't
rightly call itself anything else. If SIPB wanted to be a locally or
centrally acquired third party vendor, then it would have to package
it's software as a product that the workstation owner, or Athena
Release Engineering could simply pickup and install. Currently
discuss is the only packaged product that SIPB distributes, that I
know of, and that still isn't anywhere near the shrink wrapped product
stage. To treat SIPB differently would be to create a new class of
software providers, just for SIPB.
I can't think of any real justification SIPB can give for
being treated as anything other than a third party software
provider/distributer and still be allowed complete control over the
contents of the SIPB locker. So SIPB can either productize itself,
and let Athena control the SIPB locker, or follow the same rules that
everyone else who provides software through a locker does.
--Jerry
