Hey Glyph thanks for responding so promptly! First if I understand correctly
on the server-side we have some code like:
def get_data_updates():
if (!has_updates):
return NO_DATA
return json.encode(the_updates)
and on the client side
def poll_for_updates():
while True:
response = service.get_data_updates()
if response != NO_DATA: break
sleep(1)
do_something_with_response(response)
poll_for_updates()
As far as I can tell doing this has NO guarantee that all messages are
delivered unless every server->client connection maintains a stack of "new"
messages, whereas in a message-brokered setting the server just keeps
sending "global" updates as they occur, and the broker guarantees that
clients will receive every one. Where as in this situation, since the client
is asking the server for updates, unless the server strictly maintains all
of the updates for a specific client, some of them might be thrown on the
ground.
Am I correct here?
On Tue, Oct 6, 2009 at 8:46 PM, Glyph Lefkowitz
On Tue, Oct 6, 2009 at 11:30 PM, Stephen Mattison < stephenmattison@gmail.com> wrote:
How can I implement this in Twisted?
You can use DeferredResource:
http://twistedmatrix.com/documents/8.2.0/api/twisted.web.util.DeferredResour...
or you can return NOT_DONE_YET from Resource.render(), and hold on to the request:
http://twistedmatrix.com/documents/8.2.0/api/twisted.web.resource.Resource.h...
to leave the connection open until something happens.
For a more elaborate example of a long-polling server component, you could see Nevow's Athena:
http://www.divmod.org/trac/wiki/DivmodNevow/Athena
This does not implement JSON-RPC or XML-RPC, but it has lots of code for managing the outstanding connection, which may give you some ideas.
-Glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Stephen Mattison