Subject: Re: [cells-devel] Booyah!! openair off the ground In-Reply-To: 47F91574.8040608@optonline.net References: a70cc98c0804050550x796539cduef259247e875ab42@mail.gmail.com 47F7C616.6010004@optonline.net 47F7E848.2070504@optonline.net 18424.63017.660090.684646@martin.lyndoch.net 47F91574.8040608@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