Hi Roger, hi Jeff,
>See this for more information, but don't ask me if it's working.
It works at least for our purposes. We are using an experimental LivePage
application here at our institute. "Experimental" means that 4 subjects of
a psychological study share a message board via browser live pages.
Jeff Rush wrote:
>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
>around and periodically shoves bits of data (XML, JSON, whatever) down
>provides server => client communications via a brief REQUEST and a
>RESPONSE chunked up into pieces representing operations run on the client.
>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
>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
>the thread or a piece of state associated with (1) above, so that the
>and client have a meaningful basis on which to talk.
I struggled with both problems in the zorg.live package.
(1) In this package I implemented a specialization of the twisted server
which handles LivePage requests outside Zope's threads. Otherwise the
number of connected clients would have been limited to the number of Zope
threads which come with their own object caches and database connections,
in my view an unnecessary overhead for most LivePage requests.
(2) Each client is registered on the server side in a thread safe global
utility. This utility handles the clients ids which are send as parameters
of each LivePage request.
Feel free to contact me if this looks interesting to you.
Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Tel. +49 7071 979-208
Fax +49 7071 979-100
Zope3-dev mailing list