[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
:zztp: Proposed ZigZag Transfer Protocol ( zztp.D9
- To: zzdev@xxxxxxxxxx
- Subject: :zztp: Proposed ZigZag Transfer Protocol ( zztp.D9
- From: Ted Nelson <ted@xxxxxxxxxx>
- Date: Sun, 11 Nov 2001 20:46:14 +0000
- Cc: ted@xxxxxxxxxx, lac@xxxxxxxxxxxxxxx
(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
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.
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.
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 ... )
whichcursor OP abcell
- '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
cur1 STEP +d.1
1 50 101
cur2 HOP -d.3
2 57 203
cur7 SHEAR +d.1 -d.2 [ 'shear' is one of the several operations that
can have as many parameters as desired ]
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
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
whichcur STEP absdir
cur1 50 101
whicn in turn couldbe
1 50 101
We send to the particular cursor object the STEP op and absolute direction--
which sends to the STEP object the absolute direction
The STEP object performs the operation and returns the current position
of cursor 1
==== 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--
- 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