-*- Text -*-
   This is the file .../info/SPOS.nfo, which contains info 
about the Secure Persistent Object Server used as the standard MOOSE medium
for storing data. SPOS is to MOOSE what File Systems are to more traditional
Unix/POSIX-like OSes (which use file as their universal clumsy object).

File: SPOS.nfo		Node: Top	Up:(MOOSE.nfo)


   SPOS is MOOSE's Secure Persistent Object System.

   (Generic) Objects and not Files (1) are MOOSE's universal concept; thus
MOOSE must provide not File Systems, but "Object Servers",  This is the why of
the SPOS.
   Persistence means that Objects remain for a long time, longer even that the
running time of a session (i.e. the computer may be shut down and the objects
would remain).
   Security means that in whatever condition a shutdown may occur, objects
should reapper in a consistent way (of course the quality of the shutdown will
matter to that of the SPOS' state).


(1) Unix and old Oses support very restricted objects called Files and Tasks,
with all the complicated semantics added to special files (devices, pipes,
ttys, sockets), tasks (e.g. the kernel, daemons), client objects (users), and
all the unsecurity provided by the absence of system-supported file format.



Two layers model:
- logical layer: what objects see.
- physical layer: what is written on disks.

* Grain adaptation
  - Logical units of persistent medium (commonly disk) space allocation should
  be the same as the processor's data units. That is byte, word, and page (in
  general).
  - In the case where several processors share the same medium, we can merge
  all the units in a single list.
  - assuming units of each processor are multiples or dividors of the units of
  the other one (which is true if units are power of two's as is usual),
  this is not a problem at all.
  - the list can be expanded indefinitely; units that may correspond to medium
  specific limitations (such as sector/track/cylinder size on disks) can be
  introduced or not.
  - The used (usable) part of the disk (e.g. the disk partition) is the
  ultimate allocation unit. As you may guess, it is always allocated by the
  SPOS and divided into smaller units.
  - Units, from the disk down, are either allocated or free.
  - if they are allocated, they may be allocated as a whole, or divided into
  smaller units; an object may or not be divided using every smaller size
  available. Remnants of division into smaller units are themselves divided
  into usable units until no unit is fine enough to cover it.
  - before the division is done, a Unit Allocation Table (UAT) is written at
  the beginning (optionally in the middle ?) of the object allocated,
  explaining how the unit is divided, and whether each contained unit is
  allocated or not.
  - Perhaps the UAT should contain 
  - to simplify things, the division scheme should be decided uniformly on the
  SPOS.
* Directories
  - objects allocate pages of different size. Commonly, objects will try to
  allocate as large blocks as possible, but won't allocate units that they
  wouldn't fill.
  - The first undivided allocated object on disk is the 
  - you can group objects so that logically grouped objects will share the
  same physical pages. By default, you share pages with objects in the same
  directory.
  - 
* Disabling Grain Adaptation:
  - objects that don't want to be endangered by a general breakdown may
  refuse to share their pages with other objects. If there are different
  increasing page sizes, you can tell with size is good (commonly, 

* Security:
  - an object will not be modified on the directory, and its unit list won't be
  modified before its contents are written.
  - is considered atomic an access to a single track or to a single sector, at
  the FS administrator's choice. Perhaps objects should choose themselves ?
  -
...

Questions:
* bi- or uni- directional links ?
* atomicity of operations: ?
* links between multiple SPOSes ?
* Same SPOS accross multiple hardware devices
* Sharing writeable floppies with other computers !
