% MAKE SURE YOU EDIT THE RIGHT FILE, int.ptex and not the int.tex
% file where gpic has already expanded things.
\documentclass{article}

\usepackage{rcs}
\RCS $Date: 1999/12/23 01:53:35 $
\RCS $Revision: 1.3 $
\date{Rev.\RCSRevision~~\RCSDate}

\title{Interfacing ZigZag with ``normal'' programs}
\author{Tuomas J.~Lukka}
\begin{document}
\maketitle

\def\zz{ZigZag}

\section{Introduction}

\zz\ defines a coherent universe of cells and things that happen
when cells are modified and connected to each other.
However, since the computer and windowing system underneath don't know
anything about \zz, there is a level on which the \zz\ abstraction
and ``normal'' programs in e.g.~Java meet, so that \zz\ can be implemented
in e.g.~Java.
Because \zz\ is so different from our usual programming concepts,
an interface like this is not trivial to design correctly and
efficiently.

While the basic operations are simple, i.e.~get neighbour, connect,
create new cell etc., the handling of the interface in a coherent way
on both sides is not simple.
As an example of the difficulty, consider 
keeping a list of some attributes that you want the screen to show.
It doesn't matter what these are attributes of, or how they are shown.
We are concerned with the list itself. 

\section{Model-View-Controller}

When programming with \zz, the MVC (Model-View-Controller) representation
is a useful abstraction, the point being that all the relevant information
is kept inside the \zz\ space with many different views of the same
data being then  possible.

Let us then expand on the list-of-attributes problem.
The natural representation for a list of attributes
is rank along some dimension
in the \zz\ space, beginning at some designated cell. 
Having the list in the \zz\ space gives the system the kind of
programmability and coherence which you won't find anywhere else.
However, this programmability and coherence does not come entirely 
free. The trouble is when your e.g.~Java code which actually handles
the drawing on screen wants to use the list.

Just reading the list with the above operations is easy, you just
start at the designated cell and work your way through the list.
The trouble starts when the user modifies the list. At that point,
the user's expectation is that the display will change accordingly.
So your program should realize that the list changed.

This can be handled through callback routines but the problem is
keeping the callbacks up to date as well and handling the overzealous
callbacking with grace (e.g. if the user makes many modifications and
some while the system is busy rerendering the graph). 

\section{Synchronization}

When several concurrent processes or threads are active on the 
same \zz\ space, care is necessary to avoid race conditions (as
in all other programming with concurrent streams of execution).



\section{A proposed solution: {\tt d.watchers} and {\tt d..watching}}

As seems to happen often with \zz, the problems can be partially
solved by moving the system to \zz\ space. 
So, why not have two dimensions (see the section on relcells 
in the Gentle Introduction) showing the relationship between 
nodes representing observers and nodes representing watchers?

This simplifies things because there will be one cell on the \zz\ side
representing the Java object which is observing a group of cells.
The ``A observes B'' relation is encoded into the \zz\ structure
as in Fig.~\ref{fig-enc}
and makes it possible visualize and {\em debug} what is going on. 

\begin{figure}
\caption{Encoding watching relations in the \zz\ structure.
Watcher A watches both cells 1 and 2 and watcher A only watches 
cell 1.}
.PS
A: box "Watcher B" height 0.25
arrow "\tt d..watching" ""
box "" same
up
move to last box.n
line <- "~\tt d.watchers" ljust
R1: box "" same
right
move to last box.e
arrow
R2: box "" same
move to R1.w
left
line <-
B: box "Watcher A" same
move to R1.n
up
line <-
box "Cell 1" same
move to R2.n
line <-
box "Cell 2" same
.PE
\centerline{\raise 1em\box\graph}
\end{figure}

Also, the relcells can be put to another use beyond just showing
that there is a relation
in this design: they show the {\em kind} of watching relation, 
i.e.~contain a list
of things that the other cell is observing about the observed cell,
such as the content or the connections along some subset of dimensions.
This makes it easier to avoid unnecessary work in the list example
if someone wants to comment (along {\tt d.comment}) on one of
the cells in the list.

Even more pleasantly, this design will fit in nicely with Clang:
the cell which is observing can just as well be a Clang script.

\section{Designing \zz-code interfaces}






\end{document}

%
% vim: set syntax=tex :