[Zope3-dev] Zope 3 lacks Ajax capability?

[Jim Washington]

Jeff Rush wrote:
> 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.
>
In my recent experiments with wsgi middleware, the twisted publisher in
Zope 3 will do "chunked" transfer-coding when the published object is an
iterator that is specifically not a list or tuple. 

hth,

-Jim Washington