Andy Chambers OKed me sharing this from the cells-devel list:
"I've picked off some of the low-hanging fruit in an effort to make
hunchentoot handlers cells-aware. Most of the code so far has just been
doing the equivalent of deftk but creating "html" widgets instead of tk
ones.
http://gitorious.org/projects/hunchncells
The way this will work I think is as follows:- (most of this is vaporware)
1) request comes in from hunchentoot
2) cells handler gets "root" family object from hunchentoot session
(or creates a fresh one)
3) kick off the propagation by setf'ing the request slot on root
4) an initial response is created from the xhtml slot of the root
...user does something on the browser end...
5) make ajax call to updates service
6) the update handler feeds some new paramaters into the model
5) observers on .kids, and .value log changes into an updates slot on
the root
6) the updates are sent back down to the client
The updates would be a list of strings representing updates to the
DOM. When it gets to the
client, it is simply eval'd and hopefully, the page reflects the new state.
Here's some other stuff I've been thinking about.
1) In celtk, it seems like pretty much all events are sent from tk to
cells for handling by the widget-event-handle. I think that doing the
same for javascript events would be too expensive. Perhaps we could
classify events into those that need to be sent immediately, those that
can be sent periodically (say every 5 seconds), and those that can be
ignored. I think even this would be probably not be scalable but
I don't work for google so I don't have to worry about that ;-) .
2) How do we feed these javascript events into the model? This would
probably be another handler on a different url that listens for events
specified as ajax GETs like this...
GET /events?event=change&id=I034&new=somevalue
It feeds these onto an events slot on the model and returns the current
value of the updates slot mentioned above to the client."
<<<<<<<<< end of quotation >>>>>>>>>>>>>>>
The fun thing is that Andy took Celtk as his starting point, with
browsers playing the part of the Tcl/Tk Universe driven by Celtk, just
as Vasilis Margioulas used Celtk as his starting point for Cells-Gtk.
The trick they all share is to have a Lisp CLOS Cells Inside(tm) model
churning away and using observers to drive a parallel universe (GTk, Tk,
or browser) experienced by the user.
Makes me wonder if we are not also on the tail of that new Air thingy
from Adobe Flash/Flex/whatever (apps deliverable as RIA or desktop): if
we do it right, the same RIA Web app could be a desktop Celtk app.
Probably easiest to give Hunchncells an alternate Celtk backend. But I
digress...
I'll be doing what I can to help Andy, but I won't be much use on
anything but the Cells. If anyone else wants to get involved Andy is
doing most chatting I can see on cells-devel, you can find him there or
here.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
And I responded:
"Andy Chambers wrote:
> I've picked off some of the low-hanging fruit in an effort to make
> hunchentoot handlers cells-aware. Most of the code so far has just been
> doing the equivalent of deftk but creating "html" widgets instead of
tk ones.
>
> http://gitorious.org/projects/hunchncells
>
> The way this will work I think is as follows:- (most of this is
vaporware)
>
> 1) request comes in from hunchentoot
> 2) cells handler gets "root" family object from hunchentoot session
> (or creates a fresh one)
> 3) kick off the propagation by setf'ing the request slot on root
> 4) an initial response is created from the xhtml slot of the root
> ...user does something on the browser end...
> 5) make ajax call to updates service
> 6) the update handler feeds some new paramaters into the model
> 5) observers on .kids, and .value log changes into an updates slot
on the root
> 6) the updates are sent back down to the client
Sounds good, tho of course the devil is in the details and I am new to
all this interwebby stuff.
Food for thought if it comes up: Cells3 introduced a mechanism whereby
observers could queue their output to a client-queue and likewise
specify a client queue handler for those cases where custom handling is
required. Tk, eg, is a little fussy about the order in which things
happen, so observers (who do most of the talking to tk) rather than
talking directly to tcl/tk had to queue up their actions along with a
keyword used by a tk-specific client-q handler to sort things into the
right order.
eg, if you are introducing a new node to the dom in one place and
referencing it in another, mebbe you have to make sure those bits go to
the browser in that order (create before reference) and you'll need to
borrow that bit as well from Celtk.
>
> The updates would be a list of strings representing updates to the
> DOM. When it gets to the
> client, it is simply eval'd and hopefully, the page reflects the new
state.
Flapjax, OpenLaszlo move over! :)
>
> Here's some other stuff I've been thinking about.
>
> 1) In celtk, it seems like pretty much all events are sent from tk to
> cells for handling
> by the widget-event-handle. I think that doing the same for
> javascript events would be too
> expensive.
Right, Celtk uses the C FFI so we can pin our ears back and go, LTk does
not have that much performance hence access to the event stream.
> Perhaps we could classify events into those that need
> to be sent immediately,
> those that can be sent periodically (say every 5 seconds), and
> those that can be
> ignored. I think even this would be probably not be scalable but
> I don't work for
> google so I don't have to worry about that ;-) .
>
> 2) How do we feed these javascript events into the model? This would
> probably be another
> handler on a different url that listens for events specified as
> ajax GETs like this...
>
> GET /events?event=change&id=I034&new=somevalue
>
> It feeds these onto an events slot on the model and returns the
> current value of the
> updates slot mentioned above to the client
I am afraid it's all Greek to me, but if you really need the input lemme
know and you can bring me up to speed on the technology.
If this is at all relevant, I have always anticipated a Cells.js support
module to make it all go."
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 26, 11:29 am, Ken Tilton <···········@optonline.net> wrote:
>
> The way this will work I think is as follows:- (most of this is vaporware)
>
> 1) request comes in from hunchentoot
> 2) cells handler gets "root" family object from hunchentoot session
> (or creates a fresh one)
> 3) kick off the propagation by setf'ing the request slot on root
> 4) an initial response is created from the xhtml slot of the root
> ...user does something on the browser end...
> 5) make ajax call to updates service
... Time Passes ...
> 6) the update handler feeds some new paramaters into the model
> 5) observers on .kids, and .value log changes into an updates slot on
> the root
> 6) the updates are sent back down to the client
I don't know much about lisp, but I am really trying to learn.
I do know a lot about HTTP and building websites and such. Here's my 2
cents.
Other than the fact that you would have a long wait between changes in
the client state and updates to the client, this might just work. In
other words, the latency is a deal breaker.
You're better off treating the web server as a backend with high
latency. They end up that way eventually anyway. That means you either
have to give the user a crappy experience waiting for pages to load
because the client is implemented on the server side (think VNC) or
you have to make a really smart client that only makes requests to the
server when absolutely necessary (think email IMAP client). The
current state of AJAX says that maybe we should be trying to build the
latter rather than the former.
Jonathan Gardner wrote:
> On Mar 26, 11:29 am, Ken Tilton <···········@optonline.net> wrote:
>
>>The way this will work I think is as follows:- (most of this is vaporware)
>>
>> 1) request comes in from hunchentoot
>> 2) cells handler gets "root" family object from hunchentoot session
>>(or creates a fresh one)
>> 3) kick off the propagation by setf'ing the request slot on root
>> 4) an initial response is created from the xhtml slot of the root
>>...user does something on the browser end...
>> 5) make ajax call to updates service
>
>
> ... Time Passes ...
>
>
>> 6) the update handler feeds some new paramaters into the model
>> 5) observers on .kids, and .value log changes into an updates slot on
>>the root
>> 6) the updates are sent back down to the client
>
>
> I don't know much about lisp, but I am really trying to learn.
Um, ya wanna good way to learn some?
hth, kenny
>
> I do know a lot about HTTP and building websites and such. Here's my 2
> cents.
>
> Other than the fact that you would have a long wait between changes in
> the client state and updates to the client, this might just work. In
> other words, the latency is a deal breaker.
>
> You're better off treating the web server as a backend with high
> latency. They end up that way eventually anyway. That means you either
> have to give the user a crappy experience waiting for pages to load
> because the client is implemented on the server side (think VNC) or
> you have to make a really smart client that only makes requests to the
> server when absolutely necessary (think email IMAP client). The
> current state of AJAX says that maybe we should be trying to build the
> latter rather than the former.
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 27, 12:15 am, Jonathan Gardner <········@jonathangardner.net>
wrote:
> On Mar 26, 11:29 am, Ken Tilton <···········@optonline.net> wrote:
>
>
>
> > The way this will work I think is as follows:- (most of this is vaporware)
>
> > 1) request comes in from hunchentoot
> > 2) cells handler gets "root" family object from hunchentoot session
> > (or creates a fresh one)
> > 3) kick off the propagation by setf'ing the request slot on root
> > 4) an initial response is created from the xhtml slot of the root
> > ...user does something on the browser end...
> > 5) make ajax call to updates service
>
> ... Time Passes ...
>
> > 6) the update handler feeds some new paramaters into the model
> > 5) observers on .kids, and .value log changes into an updates slot on
> > the root
> > 6) the updates are sent back down to the client
>
> I don't know much about lisp, but I am really trying to learn.
>
> I do know a lot about HTTP and building websites and such. Here's my 2
> cents.
>
> Other than the fact that you would have a long wait between changes in
> the client state and updates to the client, this might just work. In
> other words, the latency is a deal breaker.
>
> You're better off treating the web server as a backend with high
> latency. They end up that way eventually anyway. That means you either
> have to give the user a crappy experience waiting for pages to load
> because the client is implemented on the server side (think VNC) or
> you have to make a really smart client that only makes requests to the
> server when absolutely necessary (think email IMAP client). The
> current state of AJAX says that maybe we should be trying to build the
> latter rather than the former.
I haven't got to the stage of dealing with this yet but javascript has
associative arrays right? We could use these to cache the results of
ajax requests.
Anyway, this is getting off-topic for this group but if your
interested, clone the git repo and subscribe to cells-devel. I'm
pretty new to Lisp too and doing this has helped me learn CLOS and
macros (both of which seem to be near the top of most people's "Why I
use Lisp" lists).
Andy Chambers wrote:
> On Mar 27, 12:15 am, Jonathan Gardner <········@jonathangardner.net>
> wrote:
>
>>On Mar 26, 11:29 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>
>>
>>
>>>The way this will work I think is as follows:- (most of this is vaporware)
>>
>>> 1) request comes in from hunchentoot
>>> 2) cells handler gets "root" family object from hunchentoot session
>>>(or creates a fresh one)
>>> 3) kick off the propagation by setf'ing the request slot on root
>>> 4) an initial response is created from the xhtml slot of the root
>>>...user does something on the browser end...
>>> 5) make ajax call to updates service
>>
>>... Time Passes ...
>>
>>
>>> 6) the update handler feeds some new paramaters into the model
>>> 5) observers on .kids, and .value log changes into an updates slot on
>>>the root
>>> 6) the updates are sent back down to the client
>>
>>I don't know much about lisp, but I am really trying to learn.
>>
>>I do know a lot about HTTP and building websites and such. Here's my 2
>>cents.
>>
>>Other than the fact that you would have a long wait between changes in
>>the client state and updates to the client, this might just work. In
>>other words, the latency is a deal breaker.
>>
>>You're better off treating the web server as a backend with high
>>latency. They end up that way eventually anyway. That means you either
>>have to give the user a crappy experience waiting for pages to load
>>because the client is implemented on the server side (think VNC) or
>>you have to make a really smart client that only makes requests to the
>>server when absolutely necessary (think email IMAP client). The
>>current state of AJAX says that maybe we should be trying to build the
>>latter rather than the former.
>
>
> I haven't got to the stage of dealing with this yet but javascript has
> associative arrays right? We could use these to cache the results of
> ajax requests.
>
> Anyway, this is getting off-topic for this group...
Is that actually possible? :)
I am wondering (so I can learn) *precisely* where Jonathan sees the
perofrmance problem, how Ajax does it better, speaking of which how what
you are doing is not Ajax, and why we cannot do the same thing.
I was thinking we want as much granularity as possible in both
directions, but bundling up multiple transfers (in either direction) so
just one is done per event.
This is kinda like cells-ode. ODE is moving in discrete steps, changing
many things in each step. That translates to just one Cells update, no
matter how many data points have changed in one ODE sweep (and I did
something to support that recently -- client control over propagation or
something).
btw, I think you mentioned giving the developer control over what gets
moved eagerly and what not. Is that relevant, or did I completely
misremember?
> but if your
> interested, clone the git repo and subscribe to cells-devel. I'm
> pretty new to Lisp too and doing this has helped me learn CLOS and
> macros (both of which seem to be near the top of most people's "Why I
> use Lisp" lists).
Not learning Cells? <sniff>
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius