created mirror

Documentation/Interfacing/Makefile

@@ -0,0 +1,6 @@
+int.dvi: int.ptex
+	gpic -t <int.ptex >int.tex
+	latex int.tex
+ps: int.ps
+int.ps: int.dvi
+	dvips int

Documentation/Interfacing/int.ptex

@@ -0,0 +1,141 @@
+% 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 :