Re-writing_gzz_impl.html from gzz at Krugle

Show Re-writing_gzz_impl.html syntax highlighted

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Re-writing gzz.impl</title>
                           
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
  <body>
       
<h1>Re-writing <tt>gzz.impl</tt> with a core gridwalker</h1>
       
<h2>The Problem (aka the current implementation)</h2>
    Our current implementation of the Gzz core is just <i>horribly</i> complex.
  Every time we implement some new functionality or optimization, even if
it  initially sounds very simple and clear we end up putting patches in lots
 of places, because there are <i>so</i> many interactions of... everything
 with everything.<br>
    <br>
    Here are some examples of what you may have to consider when implementing 
something  new:<br>
       
<ul>
      <li>How will it work with included spaces</li>
     <li>How it will work with VStream dimensions</li>
   <li>How it will work with undoability</li>
   <li>How it will work with loading from and saving to the disk</li>
   
  <ul>
     <li>How block-local IDs will be transformed into global IDs when loading</li>
     <li>How temporary IDs will be transformed into permanent IDs when saving</li>
     <li>How these two transformations interact</li>
                   
  </ul>
 
</ul>
     
<h2>         Timing: the 50 &micro;s        </h2>
   For views to work smoothly enough, i.e.to start the animation within 100ms 
 of a keypress, we can allow approx. 50&nbsp;&micro;s for moving from one 
cell to the next.<br>
   <br>
  This is easily enough for some hashtable lookups but for virtual cells
it  might not be possible at all without caching.<br>
     
<h2>    The solution: a local, physical space (`Leo')</h2>
The solution is what we call <i>Leo</i>, after Leo Tolstoi, who believed
that only what he could at some moment see did really exist (sometimes when
taking a walk, he would turn around quickly, trying to catch a look at how
things would come into existance only when he'd look at them). Leo will be
a component containing only <i>part</i> of a space-- caching cells and connections
from different slices, spaceparts and so on. The space is stored in hashtables,
as in the simplest implementations. When traversing  a connection, it can
happen that either<br>
   
<ol>
    <li>the connection is in the hashtables -&gt; traverse</li>
    <li>there is an indication in the hashtable that the connection is null
 -&gt; return</li>
    <li>there is an indication that there is a hook (not-yet-loaded cells)
 on the connection -&gt; request spacepart to create the cells and retry</li>
   
</ol>
This has two immediate benefits:<br>
<ul>
  <li>Spaceparts with virtual cells need not worry about time that much:
After a connection has been loaded, Leo can traverse it in less than 50 &micro;s
without ever calling the spacepart.</li>
  <li>Spaceparts can be programmed more naturally: When generating a virtual
structure, they can put in a chunk of related connections together, instead
of having to re-construct the structure internally at each <tt>s()</tt>tep.</li>
</ul>
       
<h3>Hooks</h3>
<h3>Preflets<br>
</h3>
<h2>Notification</h2>
Many kinds of spaceparts need to be notified when changes are made to their
cells, or sometimes the cells of other spaceparts. Purposes of notification
include:<br>
<ul>
  <li>Maintaining undo lists in slice spaceparts;</li>
  <li>Updating cells' texts in vstream spaceparts;</li>
  <li>Changing a Nile Table of Contents when the vstream changes, and changing
the vstream when the TOC changes;</li>
  <li>Moving files when they're reconnected in a filesystem spacepart.</li>
</ul>
The "classic" Gzz way of dealing with these needs is the <tt>Obs</tt> system.
However, the needs are different. The <tt>Obs</tt> system allows us to attach&nbsp;<tt>
Obs</tt> even to very complex actions, such as building a whole view, by
attaching the same <tt>Obs</tt> to every connection traversed in the process.
<br>
<br>
Here is a simple proposed interface dealing with these needs:<br>
<blockquote><tt>void connected(Cell c, Cell d) throws ZZCannotConnectException;<br>
void disconnected(Cell c, Cell d) throws ZZCannotDisconnectException;</tt><br>
  </blockquote>
Note: The idea here is that the methods are called after the connection is
made or broken, so that the spacepart can conveniently read the data as it
is now if it needs to, but if a <tt>CannotConnect</tt> or <tt>CannotDisconnect</tt>
 is thrown, the change is unmade. This allows spaceparts full control over
what of their data is mutable and in which ways.<br>
  <br>
It's not yet clear whether this should go into <tt>Spacepart</tt>, or whether
it would pay off to make a <tt>ChangeListener</tt> interface and have <tt>
Spacepart</tt> inherit from it.<br>
  <br>
(In <i>all</i> of these cases though, sometimes we do <i>not</i> want to
be notified of a change: notably, when we've done it ourselves. When we undo
a <i>connect</i> we don't want to put our <i>disconnect</i> on the undo list;
when updating a cell's text we don't want to go off trying to update the
cells in the vstream accordingly, yielding an infinite loop; etc. The simplest
way to avoid this is probably to have a boolean instance variable set to
true while we're doing something ourselves, and ignore notifications then.)<br>
           <br>
       
  </body>
  </html>
See more files for this project here