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