[cells-devel] observer design question

[Ken Tilton]

Frank Goenninger wrote:
> Andy,
> 
> I don't get what you want to achieve...
> 
> Am 28.03.2008 um 14:17 schrieb Andy Chambers:
> 
>> My model consists of a family tree of objects all of which have an
>> xhtml ruled cell.  The client needs to
>> be updated if the value of this slot has changed.  However, a change
>> in one would cascade up
>> the tree so if we were logging these changes, and sending them down to
>> the client, one of the
>> things we send would be the entire document which is not what we want.
>>
>> How do I set up the observer to log the change only if it has not been
>> accounted for already.
> 
> 
> Is it:
> 
> A kid's observer is firing due to a change but that change should not  
> be reaching the client because the parent's observer's firing is  enough 
> for the (web) client to react to? If so, you could suppress the  sending 
> of a web client update when *parent* is bound and is not nil  (this is 
> meant to mean: I have a parent, so I am a kid. As a kid I  don't need to 
> update the client).
> 
> ???
> 

This is an interesting case where we can get some efficiency where the 
engine we are driving allows it. DHTML lets us change a specific node in 
the DOM without resending a whole page, OpenGL lets us rebuild a display 
list and have it take effect whenever any larger display list calls it:

(defmd ogl-node ()
   (dsp-list
      (c-formula (:lazy :until-asked)
         (without-c-dependency
             (map nil 'dsp-list (kids self)))
         (let ((display-list-name (or .cache (gl-gen-lists 1)))) ; #1
             ;---start building this list -----
             (gl-new-list display-list-name gl_compile)
             (ix-paint self)
             (gl-end-list)
             ;---end building
             (setf (redisplayp .og.) t) ; Note #2
             display-list-name))) ;; always the same once allocated

#1 display-list-name (actually just an integer) is like an OpenGL object 
ID. When larger structures render, they render kids by "calling" the 
kids' display lists by these names. gl-call-list or something.

#2 notice that this rule mutates the display list, it does not allocate 
a new one. (The whole scheme breaks down if we do that.) So we will 
forever be returning the same "name" and so the Cells engine will not 
see any change. Observers will not run and (crucially) users will not 
get invalidated. This is way cool because this is exactly what we want. 
The only dependencies arise during that call you see to IX-PAINT. If I 
reference any other cell and that changes, then when the name slot gets 
sampled Cells will kick off the rule to rebuild the list.

When do they get sampled? I think the display callback runs down the 
visual hierarchy sampling each node's list to get it rebuilt before 
runnning down it again to actually render -- you cannot build a display 
list and render at the same time.

So it is both a little awkward yet strangely Cells-friendly.

kt