-*- Mode:Text; Fonts:(MEDFNT MEDFNB) -*-

We need a method for maintaining sources (e.g. Lambda or K
system, Picon) on multiple hosts that are not physically
connected to the same Ethernet.  An interface protocol that
communicates via RS-232 serial I/O is therefore proposed to
accomplish this.

Semi-standard, existing protocols, include:

1] Lambda1 SLIP* protocol.
  
  SLIP stands for "SeriaL Internet Protocol".  It is in use at MIT
  on various systems, notably DEC-10s, to provide serial gateways
  between LANs (Local Area Networks).
  
  Pros: Provides the level of transparent, easy access that programmers
  have become accustomed to.  A true TCP between LANs would be
  wonderful; providing Chaosnet as well would be a valuable
  extension.
  
  Cons: Expensive; requires high-bandwidth, near-constant dial-up
  access between machines.  Development time may be prohibitive.

2] Unix1 UUCP
  
  *Provides mail and file transfer between Unix systems.
  
  Pros: well-developed, functional protocol.  Works well between,
  e.g., Berkeley 4.2 Unix hosts.
  
  Cons: doesn't work well on Lambda-Plus systems. Most other LISP
  machines don't have Unix co-processors.  Hard to support; fairly
  buggy.

Because of the drawbacks listed above, I propose that we develop
our own, "quick and dirty" protocol.  Below I outline the
functional and design considerations for such a protocol which I
(loving acronyms as much as anyone) call "DISC-L", which
stands for "Distributed Source Control (for LISP)".

	  *********************************************
	  *** DISCUS-L:                             ***
	  *** Distributed Source Control (for LISP) ***
	  *********************************************

Objectives:

1) Provide LISP programmers at separated sites, on different
types of hosts, with source consistency control mechanisms.
Allow users to maintain parallel but distinct copies of sources,
but establish the concepts of "ownership" and "reservations"
implemented in industrially accepted source control systems.

2) Minimize inter-processor communications; put off most of the
work until specified times of day or night, performing updates
in batches.

3) Provide maximal portability between computers of different
types.

4) Provide maximal integration within the host system's LISP
facilities (command interface, editor, compiler, etc.).

The best analogy here is an ATM (Automated Teller Machine)
network. Such systems strike a balance between local convenience
(functions that can be performed through the ATM) and central
control (maintaining account balances, monthly statements,
etc.).  A poor ATM system requires constant, uninterrupted
dial-up access to the central banking computers.  Others,
however, work in a manner similar to that described below.

1) Source Control: Owners, True Copies, and Status Databases

Identify specific files/directories as "belonging" to a
particular owner.  An owner can be a network, a host, or an
author; whatever is convenient.

A file can be edited and modified by its owner(s) at any time,
without any remote access.  The "true copy" of a file is always
the one stored at the owner's preferred location.

When a non-owner wishes to edit a file, access is granted
as follows:
  
  a) Status: the non-owner dials up the owner and gets a complete update
  of file status information on the owner's host.  The local copy
  of the file status database is replaced.
  
  b) Permission: a database at the file owner's location is
  checked to verify that the non-owner has the appropriate
  permission.  Read-only access can be granted, while the right to
  write, or re-store the "true copy", can be denied.
  
  c) Comparison: if there is a local copy, the file properties are
  compared to see if the true copy is different.  Then there are
  several possibilities:
    
    i) The non-owner has an out-of-date copy.  If the same
    out-of-date copy is available remotely, a delta-document is
    transferred, from which the "true copy" can be reconstructed at
    the local site.
    
    ii) The non-owner has no out-of-date copy.  The entire "true
    copy" is transferred.
    
    iii) The owner doesn't have the same out-of-date copy.  This case
    requires manual intervention (the non-owner needs to talk to the
    owner), because the non-owner may have forked.
  
  d) Reservation: When any party gains write access, then the
  owner's database is updated to show that the file is reserved.
  Until the file is "returned" by the non-owner, no non-owner can
  reserver the true copy for writing.  Of course, the owner can
  override the system and write an update, after which the
  reserved copy cannot be restored without manual intervention.
  
  
  e) Return: When the writer restores the file, it is saved
  locally.  If this is a "true copy", only the local database is
  updated.  If this is a non-owner's copy, a queue entry is
  made that will, when batch updates are performed, transfer the
  file and update the owner location database.

2) Mimimizing Communications: Batch Updates

When an owner wants to update his own file, only a reservation
entry in his local database is required.  If the file is already
"checked out" remotely, however, communication with the remote
system, where the file is reserved, is required.

To simplify the operations, all batch operations (i.e. file
transfers to the owner sites) are initiated by the owner's host.
At designated times, the status database is inspected.  If a set
of files is "checked out" by a remote system, the owner system
calls up the remote system and accepts its queue of batch jobs. 
  
  a) If the non-owner has returned the file, the job contains
  every piece of information required to update the true copy,
  including the new file properties and delta-document.
  
  b) For all files reserved, but returned, by non-owners, a
  reminder is posted remotely which generates a mail message to
  the non-owner.

With this methodology, if an owner urgently requires access to
one of his files, the batch updates can be initiated
immediately.  On the other hand, non-urgent updates are
postponed until a convenient (or less costly) time.

If the non-owner cannot be reached, the owner has a choice:
postpone the update until the batch operation has succeeded
(presumably until a reasonable number of retries have been
attempted), or override the reservation.  This will require 
manual intervention, perhaps a merging of the changes, at a
later time.

3) Portability - CommonLISP and Kermit

To make DISCUS-L maximally portable among LISP systems, the
reservation and database systems will be implemented in pure
CommonLISP, and Kermit will be used as the batch communications
interface.  Both are available on a wide variety of systems, and
the batch transfer facility may need to be implemented in a
variety of control languages.

For example, a DCL command script in VMS may be used to process
the file transfers.  In Unix, a "crontab" entry may be required
to run a script that invokes Kermit.  On LISP machines, of
course, Kermit will be invoked by LISP directly.

4) Integration - Editor Features