142 lines
4.6 KiB
TeX
142 lines
4.6 KiB
TeX
% 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 :
|