[cells-devel] (no subject)

[andy]

Subject: Re: [cells-devel] Booyah!! openair off the ground
In-Reply-To: <47F91574.8040608 at optonline.net>
References: <a70cc98c0804050550x796539cduef259247e875ab42 at mail.gmail.com>
	<47F7C616.6010004 at optonline.net>
	<47F7E848.2070504 at optonline.net>
	<18424.63017.660090.684646 at martin.lyndoch.net>
	<47F91574.8040608 at optonline.net>
X-Mailer: VM 8.0.9 under Emacs 22.1.1 (i486-pc-linux-gnu)

Ken Tilton writes:
 > andy wrote:
 > >  > >> 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.

Mmm.  Not going too well here.  webactions seems to require something
called :sock that doesn't appear anywhere on cliki.net.  Does this
come pre-installed with allegro?

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

 > > 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.

google does a fair amount of clever stuff with javascript.  I'm sure
there must be some fairly advanced caching going on there.

 > 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...

I've heard of cases where it isn't.  Not quite sure how that happens
though.  I think the GC is a good idea and it doesn't sound like it'll
be that hard.


 > >  > 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"/>

You can now put XML on your resume :-)

 > 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>

We don't even have to invent a new syntax.  You can define javascript
objects using a syntax almost exactly like that...

var cache = {
 l123 : "<li id=\"l123\"><xref ref=\"s123\"/></li>"
 s123 : "<span id=\"s123\">progv</span>"
};

then if we need to update it...

cache["l123"] = "<li id=\"l123\"><xref ref=\"s124\"/></li>";

--
Andy