[cells-devel] Booyah!! openair off the ground

[Ken Tilton]

andy wrote:
> Ken Tilton writes:
>  > Ken Tilton wrote:
>  > > Awesome subject. :)
> 
> :-)
> 
>  > >> I just wanted to see it working before reading up on aserve's
>  > >> webobjects and adding support for them so kenny can see this in
>  > >> action.
>  > > 
>  > > 
>  > > OK, so I should wait?
> 
> Yeah.  I'm working on that now so I'll let you know later this goes.

Cool. I am working on Cells.js. :)

> 
>  > > I have been thinking about that edge case with a grandparent and 
>  > > grandchild changing but not the parent. One thing to do (besides what I 
>  > > think we should do, viz. xlookup) would be to extend cells to allow 
>  > > something like, ok, this reference to another cell is a dependency, but 
>  > > make it a lazy (non-propagating) dependency. This, btw, could be 
>  > > achieved by recording the other cell as /used/ but not recording me as a 
>  > > user. Which makes me wonder if a synaptic cell might not do, one that 
>  > > simply never says "yes" to the question "should this new value be 
>  > > propagated?". The key here is that we want this to be 
>  > > dependency-specific. If it were rule-wide, we already have lazy cells. 
>  > > But the only dependency we want lazy is when we go after a child node's 
>  > > xml. It would be cool if a synapse Just Worked, but it would be more 
>  > > efficient to extend Cells to have lazy dependencies.
>  > > 
>  > > Another approach would be to change the html generating macros to return 
>  > > functions which will when invoked generate the XML, including child XML 
>  > > by calling /those/ nodes xhtml generators. Deferred evaluation and all 
>  > > that. Then when the grandparent rule got reran and a new function 
>  > > generated, when that got called it would call its child's function (the 
>  > > parent in the kid-parent-grandparent use case at hand) and it would call 
>  > > the kids and get the latest xhtml. I guess this is like the Lisp trick 
>  > > of letting us change a function at runtime and then have the new version 
>  > > called by an old and un-reompiled caller, the function being resolved at 
>  > > runtime.
>  > > 
>  > > And then the final approach is the xlookup thing, really deferring 
>  > > dispatch until /browser/ run-time.
>  > > 
>  > > btw, those were presented in increasing order of superiority. :) The 
>  > > first might be easiest and I will explore it a little now, the second 
>  > > might be tough or might not, and I have no clue how hard xlookup would 
>  > > be (but I am pretty sure that is not a good name for it <g>).
> 
> How about xref, or just ref.

Awesome. I kept thinking "xref" but I kept worrying about a clash, altho 
I think it was href I remembered.

It is so much fun doing this without a clue on the domain (and the more 
I look at it the less I feel bad about having missed all this <g>).

>  I don't think the name matters really
> much since xml has namespaces to avoid collisions.  We just put it in
> the http://openair.net/ (or whatever) namespace.

Ah, snazzy.

> 
> I'm going to read through the previous stuff you've posted about
> lookups since I'm still not clear about how it would work.  Here's my
> understanding at the minute.  Does it sound ok?
> 
> All the actual xml would have to be stored somewhere, presumably a
> javascript associative array.  Then, whenever something is sent to the
> browser, we find all xlookup elements and replace them with their
> associated content.

Yep. I am hoping that when you said the "x" was for extensible that this 
will work.

The crazy thing is that where browsers cache pages and images and other 
things we are taking caching to a new (is it new?) level.

I mentioned GC being a concern. Possibly we have a fallback mechanism if 
we screw that up whereby xref can -- should something requested not be 
found -- make one last try by asking the server. Of course I am hoping 
the existing not-to-be mechanism will let us keep the client-side 
dictionary (where xref looks, the js associative array) tidy, but a few 
lines of code for a fallback might be smart.

Or am I being silly about even needing GC? Well, if we are building RIAs 
then we might well end up with users hanging out for a long time on the 
same page -- that by the way is me guessing the dictionary will get 
tossed when they leave a page. Getting ahead of myself as usual...

> 
>  > > 
>  > 
>  > It occurs to me that this apropos example would benefit another way from 
>  > something like xlookup. Suppose can only guess a chunk of name that is 
>  > very common, so there are a lot of matches. That's OK, now they just 
>  > click various check boxes that limit the matching. But each time they 
>  > click on a selection criteria a round-trip is needed to ask Common Lisp 
>  > which symbols are, say, exported. Suppose a third are.
>  > 
>  > Without xlookup, the xhtml for that one third must be resent. With 
>  > xlookup, the parent just resends itself listing so many terse little 
>  > xlookup tags. GC on the client side could be handled during "not-to-be" 
>  > processing.
> 
> Just to make sure I'm not missing anything, is the comparison below
> what you consider the difference to be?
> 
> <xlookup ref="s123">
> 
> Here's the equivalent
> 
> <li id="l123"><span id="s123">progv</span></li>

No, but I am guessing it's a typo, you meant to compare with (using the 
burgeoining new name and throwing in another slash just to see if I am 
learning anything):

   <xref ref="l123"/>

ie, it's the line that does not need resending -- in general, we want to 
go as high up as possible. In fact, technically that might be 
(introducing a syntax for email discussions in which dictionary entries 
are signified thus:

   l123 : <li id="l123"><xref ref="s123"/></li>

...with this as a separate entry:

   s123 : <span id="s123">progv</span>

Overkill? Actually, overkill is usually a Good Thing, always turns out 
handy later. If we end up bogging down clients with the burden of 
forever reassembling the xhtml, we can probably do something...omigod! 
Cells may help.

Cells already has a mechanism by which it nnotices and optimizes the 
case in which a cell slot of an instance will never change, either 
because it was initialized to a non-cell value like "42" or because the 
rule ended up with no dependencies after running.

In our case, the line can see the span will never change and "in-line" 
the span instead of doing the dynamic xref thing.

Hmmm. So can the line be in-lined? It will never change, but this would 
be no good, the parent div will vary in which lines to show... well, 
maybe that is OK and I am getting ahead of myself again -- probably 
cells-js can handle this on the client side (tho a small voice tells me 
whatever guidance the Lisp side can be sure of should be offered). We'll 
see. I would go for the xref overkill unless you see some problem with 
it and let performance prove that it is a problem.

> 
>  > 
>  > When that is working we can look at implementing this bit wholly on the 
>  > client side, with Cells/js.
>  > 
>  > jes thinkin out loud.... but it does make me less interested in 
>  > exploring other ways to fix the edge case.
> 
> No problem.  We should do it right.

Ah, a man after my heart. Yeah, doing it right generally means thinking 
harder, working less, and producing something way cooler and in the end 
pragmatically much better. Most programmers duck the hard stuff and do 
things the easy way and end up in a death march.

Right now I am having fun with regex replace in netbeans transforming 
the Cells lisp code to JS. This is the first time I took this approach, 
usually I do Cells 1.0 in a new language, then 2.0, then 3.0 -- with 
triple-cells (RDF and Cells) I broke down and just transliterated the 
integrity stuff after realizing doing 1.0 was silly because I have to 
turn straight around and do 3.0 -- it is fun seeing quick results, but I 
am getting used to seeing Cells work in other languages so let's see how 
hard it is slogging thru the whole thing in one go.


kenny