[Zope3-dev] Zope 3 lacks Ajax capability?

[Jeff Rush]

Benji York wrote:
> Jeff Rush wrote:
> 
>> Just checking if I'm missing something -- with the removal of HTTP 
>> streaming/chunking in 3.2, this means that the async bi-directional 
>> persistent socket communications associated with Ajax is NOT possible 
>> at this time?
> 
> Don't know if it is or isn't, but that's a novel definition of the "A" 
> in AJAX that I haven't seen before.

I got the definition from Wikipedia:
   http://en.wikipedia.org/wiki/AJAX
"Ajax, shorthand for Asynchronous JavaScript+CSS+DOM+XMLHttpRequest, is a Web 
development technique for creating interactive web applications."

 From the page of the guy that coined the name:
   http://www.adaptivepath.com/publications/essays/archives/000385.php
   "The name is shorthand for Asynchronous JavaScript + XML".

The key points re Zope3 are:

(1) a piece of Javascript downloaded with a page request turns around and 
issues an HTTP GET back to Zope3 such that that connection is kept open 
indefinitely, and the thread within Zope3 that is servicing that request hangs 
around and periodically shoves bits of data (XML, JSON, whatever) down that 
pipe that get acted upon by Javascript within the client's page.  This 
provides server => client communications via a brief REQUEST and a neverending 
RESPONSE chunked up into pieces representing operations run on the client.

(2) another piece of Javascript downloaded with a page request similarly turns 
around and issues an HTTP GET/PUT back to Zope3 with a header to keep the 
connection open.  Over this pipe the client can issue conventional multiple 
REQUEST/RESPONSE cycles to invoke functions within the server, providing 
client => server communications.  However the trick re Zope3 is that the 
URL/view to which that request connects must be one that can rendevous with 
the thread or a piece of state associated with (1) above, so that the server 
and client have a meaningful basis on which to talk.

So far as I can see, Zope3 doesn't provide any way to (1) hang onto a thread 
that can send further response data at any time or (2) manage a rendevous with 
a thread/context of another HTTP request from the same browser.  I think I can 
implement (2) but (1) is harder until streaming is added back in.  #1 could 
also be implemented as some piece of context that is handed to an arbitrary 
request-servicing thread each time data becomes available to send to the 
client but that approach still needs some element that does computation within 
the server and then signals it has data ready to send to the client.

-Jeff