zzM: Modular ZigZag and the ZZTP breakdown ( zzM.D6)

[Ted Nelson <ted@xxxxxxxxxx>]

zzM  D6
01.11.11
========

(This is in part a sequel to "PROPOSED ZIGZAG MODULES AND THEIR
CONNECTION", zzmod.D4, 01.09.27).  It is also a companion to "PROPOSED
ZIGZAG TRANSPORT PROTOCOL", zztp.D9, and "OPERATIONS DEFINED FOR ZZTP",
zzOplists.D8.)

==========

The proposed ZigZag Transfer Protocol (earlier email) is a breakdown of
command structure which also ties in with the modular design now underway
(zzM, Modular ZigZag).  (I referred to this design a couple of weeks ago as
zzT-- these things change :) 

Modular ZigZag is intended to allow every routine to be separately compiled
and tossed into a RAMdisk, either in Windows at the MS-DOS level or in
Linux.  

We may think of this as a Cluster, or Goldfish model of synchronization,
very unlike RCS.  (Just throw it in the pool and see if it swims.)  Since
the basic model of ZigZag is very well defined, the whole system should
actually be breakable into separable parts which can be manipulated this
way.  

== ISSUES.

1)  In the earlier design paper (zzmod.d4) I talked about distributing the
gridstructure for speed, possibly having more than one mechanism for
storing different parts of the gridstructure.  This has two problems--

  - It would require a dispatching mechanism which would almost surely eat
up any gain in efficiency
  
  - If a connection were split across two different mechanisms, it would
mean having to get two halves of the answer from two mechanisms anyway.
This would also mean synchronization problems, caching, semaphores...
phooey.  
 
  So let's not bother with that, and possibly not need a dispatcher.
  
2)  How handle subroutine returns?  Since something very like subroutines
are needed, replicating subroutine functionality with
separately-addressable programs could be a pain in the neck.  Possibilities
include--

  - Some sort of a Dispatcher mechanism after all
  
  - Shell scripts.

3)  The database (especially in the prototype, which we're carving up)
irreducibly handles a number of the different operations.  Since programs
generally have only one entry point, the choices are

  - Call it with different parameters and PRETEND it's a single addressable
cell
  
  - (Better)  Assign each of the operations to a program, named after that
single addressable cell, and have THEM call the database functionalities.
This maintains the concept of the identity cell and the syntax but deals
with reality backstage.

?
_________________________________________
Theodor Holm Nelson              
Project Professor, Keio University SFC Campus, Fujisawa, Japan
Visiting Professor, University of Southampton, England
 ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
 ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
 ? Coordinates in USA      Tel. 415/ 331-4422
  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
_________________________________________