zztp: Proposed ZigZag Transfer Protocol ( zztp.D9

[Ted Nelson <ted@xxxxxxxxxx>]

zztp  D9
01.11.11
========

(This is in part a sequel to "PROPOSED ZIGZAG MODULES AND THEIR
CONNECTION", zzmod.D4, 01.09.27)
==========

What follows is a proposed syntax for sending a command to a ZZ kernel or
back-end server.  Other uses of this breakdown will be discussed later.

(It's time to think about a ZZ back-end server.  Since there actually is a
front-end ZigZag-compatible system that could work with such a server-- Les
Carr's XML version that runs in a browser, with a number of ZZ operations, at
http://www.ecs.soton.ac.uk/~lac/zigzag/
 it's time to be thinking about how to use such a page passively as a
projection screen and service it from a back end.)

(There will of course be a sync problem, considering that Les's system
might sometimes be operated locally, sometimes hooked up to a server.  We
will leave that issue till later. (I believe the solution is in my basic
Deep Slice design, often spoken of.))

This proposed syntactical sequence also breaks down nicely so that
successive tokens can be eaten by different subroutines (or object levels)
along the way.


==== ASSUMPTIONS	

KEYBOARD HANDLER.  

A typed user command is intercepted by a keyboard handler, which converts
and resolves it into a string of the type to be described shortly.  (Such a
'keyboard handler' will later manage game controllers, joysticks, etc.; for
all of these it will make the equivalent translations to this same output.)

NAMES AND NUMBERS

This is a possibly-retrograde assumption to simplify the first version.

Every cell has an absolute name, which is an integer.  In this initial
protocol it will be referred to by this integer.

IDENTITY CELLS

A cell which refers to a ZZ entity is an *identity cell*, referenced as an
integer in this protocol.

Every operation has an identity cell.  Executing the cell of that number
causes the operation to be executed.

Every dimension has two identity cells: one for the dimension taken in the
positive direction, and another for the dimension taken in the negative
direction.  Example: let us represent +d.1 as cell 101, and let us
represent -d.1 as cell 201.  We will here call 101 and 102 the "absolute
directions" of d.1.  (We may also want a third cell to refer to the
dimension considered directionlessly.)

A cursor's first identity cell is the cursor itself.  But every cursor has
two identity cells: the cursor itself (e.g. cur1), and a cell which refers
to the cell the cursor points at-- the dereferenced cursor (e.g @cur1).  


==== PROTOCOL SEQUENCE

I propose the following basic protocol sequence, to be emitted in ASCII
(e.g by the keyboard handler) and interpreted elsewhere (e.g by unified
back end or modular component routines).

While the different ZZ commands differ, I think the basic sequence should
be (with variants)

    whichcursor OP absdir (absdir, absdir ... )
    or
    whichcursor OP abcell

where
  - 'whichcursor' specifies the specific cursor (refreshed or dark)
  at which the operation will be performed
  - 'OP' is the operation name, designated as an integer
  - 'absdir' is the absolute direction on an absolute dimension, regardless
of aliases and nicknames
  - 'abcell' is the absolute cell ID, regardless of aliases and nicknames
 
Examples:
  cur1 STEP +d.1
      
      couldbe
                     1   50   101
      
  cur2 HOP -d.3
  
      couldbe
                     2   57   203
  
  cur7 SHEAR +d.1 -d.2   [ 'shear' is one of the several operations that
can have as many parameters as desired ] 
      
      couldbe
                     7   63   101   201


== WHAT THIS MEANS

IF A USER OP--
  The keyboard handler has sorted out the user-selected operation,
regardless of how it has been selected.  (Therefore the keyboard handler
must know the number of each operation, though not necessarily its string
name as known to users and programmers.)

  The keyboard handler has also sorted out the particular arrow key just
hit, crunched it against that cursor's current dimensions and their
directions.  The keyboard handler has reduced these particulars, e.g to
"+d.1" and "-d.3".   (Therefore the keyboard handler must have a map of
each cursor's current dimensions.) 

IF A CONSTITUENT SUBOP--
  If the operation is taking place as part of another operation, that
suboperation is being called with the appropriate parameters somehow selected.


==== HOW THIS PROTOCOL BREAKDOWN CAN ACTUALLY BE USED

1)  (My immediate concern.)  As a syntax for zzM (Modular ZigZag), between
free-standing operations.

  An operation is called with one argument (the operation) and the rest of
the operands, if any, are conveyed to it in a pipe.

2)  As a syntax for commands to a back end, as translated and presented to
the back end by a keyboard handler.  

3)  As a way of calling subroutines implementing higher ZZ functions.

4)  As levels of an object-oriented breakdown.  Start with the STEP
operation--
         
         whichcur STEP absdir
    
    Numerically translated--
    
         this couldbe
                     cur1   50   101  
         
         whicn in turn couldbe
                     1   50   101 
                     
  We send to the particular cursor object the STEP op and absolute direction--
   
         couldbe
                     50   101
  
    which sends to the STEP object the absolute direction
         
         couldbe
                     101
                     
    The STEP object performs the operation and returns the current position
of cursor 1
    
         couldbe
                     753
  
  
==== RETURNED INFORMATION

On the C model, an operation returns one value, the new position of the
specified cursor (which is often the same as the old position).

Other information is returned in the structure itself, which refreshes--
  - ON-SCREEN
  - possibly AS AUDIO  

through the various Show routines, as user-selected.


==== CHICKEN-EGG PROBLEM WITH THIS BREAKDOWN

An obvious problem with this structure is the assumption that a sufficient
model of the system must exist in the keyboard handler to sort out even the
primitive operations-- which might assume the full system already.

However, taken in its most general terms, this is a proposed model for a
generalized self-referential implementation.  

Clearly it can't be done this way all at once.  What will work at first is
a pragmatic issue.  It needs phasing.  

For instance, a reduced-function keyboard handler could be set up to parse
a subset of commands simply for the time being.
?
_________________________________________
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
_________________________________________