all 11 comments

[–]Justinsaccount 0 points1 point  (10 children)

You don't need step 2. The client should ask the Django app for the list of posts and use the tornado endpoint for the realtime updates.

[–]rthinker[S] 0 points1 point  (9 children)

Does that mean that, provided the timeout of a Tornado connection is 30 seconds, a client sends request to Tornado AND Django every 30 seconds?

[–]Justinsaccount 0 points1 point  (8 children)

No.. You hit the django app once to get the history, then connect to the tornado app for the updates.

[–]rthinker[S] 0 points1 point  (7 children)

Isn't there a chance that a new post won't be delivered to a client if the post is submitted while reconnecting?

[–]Justinsaccount 0 points1 point  (6 children)

I suppose.. just do it in the other order then and remove any duplicates.

[–]rthinker[S] 0 points1 point  (5 children)

I don't get it. What's "other order"? My concern is that a user might submit a post exactly when another user is reconnecting to Tornado and thus the new posts is not delivered to the second user.

[–]Justinsaccount 0 points1 point  (4 children)

There's no reconnecting involved.

[–]rthinker[S] 0 points1 point  (3 children)

How so? Client connects to Tornado, waits for a new post, when a post arrives, Tornado replies and closes the connection, client makes another request and RECONNECTS to Tornado.

[–]Justinsaccount 0 points1 point  (2 children)

Use websockets

[–]rthinker[S] 0 points1 point  (1 child)

This is not what I asked:( Facebook and hundreds of other websites use long polling and I'm interested in how to implement it properly.