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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to