Ajax live updates

Hi all,

I was wondering if anyone using either the Scriptalicious or the
SeasideAsync packages has tried using live updates to do multiple long
running processes on a page asynchronously.  Seaside appears to run all
callback in a single process forcing them to run one at a time
apparently in the order they are rendered.  I need to have several live
updates on a page and I need them to run in parallel and render as soon
as they are finished, rather than queuing up and running one at a time.
  Any ideas?

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Ramon Leon wrote:
One more thing, this is also a problem with even a single live update
that takes a while, because while it's processing, your session is
essentially frozen and clicking any other link on the page just hangs
until the long running callback is finished.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > I was wondering if anyone using either the Scriptalicious or the
> > SeasideAsync packages has tried using live updates to do multiple long
> > running processes on a page asynchronously.  Seaside appears to run all
> > callback in a single process forcing them to run one at a time
> > apparently in the order they are rendered.  I need to have several live
> > updates on a page and I need them to run in parallel and render as soon
> > as they are finished, rather than queuing up and running one at a time.
> >  Any ideas?

I am doing very long HTTP requests (in fact HTTP streaming) with the
Comet library and Scriptaculous. The latest version doesn't do any Kom
hacks anymore, it works by subclassing WAListener. Tough it is very
much work in progress, but maybe you can get some ideas from this
code?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I am doing very long HTTP requests (in fact HTTP streaming) with the
> Comet library and Scriptaculous. The latest version doesn't do any Kom
> hacks anymore, it works by subclassing WAListener. Tough it is very
> much work in progress, but maybe you can get some ideas from this
> code?
>
> Cheers,
> Lukas

I'll take a look, appreciate the pointer, hopefully I'll figure
something out.  Let me pose a question to you since you've been the
maintainer of Scriptalicious, would you consider making all
Scriptalicious callbacks async?  I mean what point is there in an
asynchronous Javascript framework bound to a synchronous server?



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Ramon,

Isn't this behaviour also associated with the nature of a web session being processed by the server as a single thread?

Which means, the server queues subsequent requests until the very first one is finished?

However it would make sense to have multiple parallel request being processed in background if each one retrieved data out of a session.

Just a thought...

Filip.



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yes, I'm just not the guy capable of fixing Seaside, hence my call for
help.  I need to be able to do this, but it's too deep for me.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Isn't this behaviour also associated with the nature of a web session
> > being processed by the server as a single thread?

A web session in Seaside is not modelled by a single thread/process,
though some similar frameworks in Java/Python try to do exactly that
to overcome the missing continuations.

> > Which means, the server queues subsequent requests until the very first
> > one is finished?

This is actually a security feature to prevent concurrency issues. It
simplifies Web application development a lot as developers don't need
to be aware of concurrent modifications within one session.

> > However it would make sense to have multiple parallel request being
> > processed in background if each one retrieved data out of a session.

Also only retrieving data can be a problem: if you have a single
data-base connection per session you could easily screw up your
connection if you start multiple queries from different threads at the
same time.

> Yes, I'm just not the guy capable of fixing Seaside, hence my call for
> help.  I need to be able to do this, but it's too deep for me.

For script.aculo.us requests it would be sometimes cool if they don't
block. I am not sure how this could be modelled the best, though I
would like to keep the current behavior as a default. Processing
requests concurrently opens many new ways to shoot yourself in the
foot!

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Yes, I'm just not the guy capable of fixing Seaside, hence my call for
> > help.  I need to be able to do this, but it's too deep for me.
>
> For script.aculo.us requests it would be sometimes cool if they don't
> block. I am not sure how this could be modelled the best, though I
> would like to keep the current behavior as a default. Processing
> requests concurrently opens many new ways to shoot yourself in the
> foot!

I investigated the idea and couldn't find an simple workaround for
this problem: There is a lot of request related state in WASession,
WARender and probably some other classes. Moreover registering and
processing callbacks is not thread-save, dictionaries in Smalltalk get
screwed up if you modify them concurrently.

My guess is that making Seaside capable of doing asynchronous request
requires a lot of changes in the core framework. After all, you have
to pay for all the convenience you get ;-)

Of course a similar trick as I use in Comet could help to solve the
problem, however with the drawback that those special requests are
handled outside the context of the Seaside session, what is usually
something you don't want.

Any other thoughts?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

OK, all good points, you're absolutely right, I hadn't considered
concurrency and now the defaults make much more sense.  So maybe something
like an asyncCallback:[] method on SUAjax so you can shoot yourself in the
foot knowingly, when necessary?  In truth I'm not worried about concurrency,
since I don't want to update or change any data, only update the UI
concurrently.  When I think about it, I'd think updating the UI is the most
common case, so I don't think it'd really matter if it was handled outside
the scope of the session.  What do you think, is this reasonable?

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> OK, all good points, you're absolutely right, I hadn't considered
> concurrency and now the defaults make much more sense.  So maybe something
> like an asyncCallback:[] method on SUAjax so you can shoot yourself in the
> foot knowingly, when necessary?  In truth I'm not worried about concurrency,
> since I don't want to update or change any data, only update the UI
> concurrently.  When I think about it, I'd think updating the UI is the most
> common case, so I don't think it'd really matter if it was handled outside
> the scope of the session.  What do you think, is this reasonable?

Yes, this could work. However updating the UI also means that you
render anchors, form elements or new AJAX callbacks that register new
action handlers. Since an AJAX request uses the same rendering context
as the initial rendering this would again lead to a bunch of
concurrency issues. As far as I understand it would require many
changes to the Seaside core framework to make rendering/registering
callbacks thread save.

Avi, what about a roadmap for Seaside 3? :-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

It could mean that, for sure, but in my case, I'm actually just wanting
to bring extra text into the UI, hotel room prices actually, to allow a
user to select a rate.  Grabbing most hotel info is quick, I have a
local copy of the data, but getting prices takes calls to other systems
via web services that can take upwards of 10 or more seconds at times,
hence my wanting to grab them asynchronously and Ajax them in when
available.  I'd be perfectly happy even with the restriction of
rendering non form data that has no effect on the state of the form
postback, no callbacks, no links, just extra info in front of the users
eyes.  I'll spend some time reading the code in Comet, hopefully I'll
come up with something.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Now I understand your problem, thanks for the example. The simples and
safest workaround (without messing with the internals of Seaside) is
probably to do the AJAX request within a different session.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Now I understand your problem, thanks for the example. The simples and
> safest workaround (without messing with the internals of Seaside) is
> probably to do the AJAX request within a different session.

Or create a custom subclass of WASession and override the method
#incomingRequest: with something like:

incomingRequest: aRequest
        ^ aRequest isXMLHttpRequest
                ifTrue: [ self responseForRequest: aRequest ]
                ifFalse: [ super incomingRequest: aRequest ]

If this is an AJAX call the request is directly processed, else the
request is scheduled trough the monitor of the default implementation.
Though, this is dangerous and has the potential to break your system:
any request can be made to answer true to #isXMLHttpRequest.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This looks interesting, I'll explore it, any suggestion on how to do the
Ajax request on a different session, and immediately expire the session
to avoid the overhead of it hanging around?

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

 > Or create a custom subclass of WASession and override the method
 > #incomingRequest: with something like:
 >
 > incomingRequest: aRequest
 >     ^ aRequest isXMLHttpRequest
 >         ifTrue: [ self responseForRequest: aRequest ]
 >         ifFalse: [ super incomingRequest: aRequest ]
 >

OK, I've had no luck with this approach, seems to be too many
assumptions about session having a current request, then updater not
being able to find its current session.  Messing with the guts of
Seaside is just beyond me right now, to many things I don't yet grok
about the continuations and callbacks and how it all fits together.

 >> Now I understand your problem, thanks for the example. The simplest and
 >> safest workaround (without messing with the internals of Seaside) is
 >> probably to do the AJAX request within a different session.

OK, since I've gotten nowhere on the first approach, is there an easy
way to do this?  I'd like to be able to just do something like this...

renderContentOn: html
   html div id: #price; with: 'searching...'

   html script:
     (html updater id: aName; asyncCallback: [:r |
       (Delay forSeconds: 10) wait. "fake long running process"
       r div id: #price; with: DateAndTime now])

and have asyncCallback somehow get a url that comes back on a new
session to prevent blocking, and immediately expire that session after
rendering so it doesn't hand around for 20 minutes.  Anyone? Anyone?


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> OK, I've had no luck with this approach, seems to be too many
> assumptions about session having a current request, then updater not
> being able to find its current session.  Messing with the guts of
> Seaside is just beyond me right now, to many things I don't yet grok
> about the continuations and callbacks and how it all fits together.

Yes, there are so many places where 'session-state' is mixed with
'request-state' that it is hard to see why it exactly breaks.

Mhh, this is sort of streaming that you do. I doubt it will work
reliable, even if Seaside would sopport multiple requests per session
(proxy-, client-timeouts).

The solution would be to do short requests only :-)

Fork the search within a separate process and poll for a result.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Mhh, this is sort of streaming that you do. I doubt it will work
> reliable, even if Seaside would sopport multiple requests per session
> (proxy-, client-timeouts).
>
> The solution would be to do short requests only :-)
>
> Fork the search within a separate process and poll for a result.
>
> Lukas

Good idea, only took a few minutes to hack it up, used a periodical,
with a high decay and a 2 second frequency. Fork during first render,
check for result on each callback, if nil, render hidden nextId to keep
decay down, if not nil render result and count on decay to stop polling
when it gets the same result twice.  Does exactly what I need.  Thanks,
sometimes a new point of view entirely changes the problem.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside