Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement waiting for new data #2

Closed
mitar opened this issue Nov 20, 2012 · 1 comment
Closed

Implement waiting for new data #2

mitar opened this issue Nov 20, 2012 · 1 comment

Comments

@mitar
Copy link
Member

mitar commented Nov 20, 2012

I was thinking that the best way to implement waiting for new data would be to add new HTTP command, for example FETCH. So when you do a GET request with start time interval parameter, you get all data from that interval to current time. If there is no data it returns you an empty list. But by doing FETCH to same URL, django-datastream would wait until data is available and then return you the data. And after it returns the data, you could open another connection with updated start time interval parameter.

Of course, it is not smart to block Django process while both client and server are waiting for data, so another approach should be used. I see two options:

  • implement custom Tornado based web server which handles FETCH requests in a asynchronous manner, similar to how django-pushserver implements it, we can then use this server instead of fast cgi process to interact with Django
  • instead of reimplementing Tornado integration, just use django-pushserver directly, redirecting on FETCH request to django-pushserver channel and requesting that new data is send to that channel

The tricky thing here is scalability, when you have multiple instances of this asynchronous server, you want that when data comes, that it is pushed to all clients listening on all instances of an asynchronous server (I am not sure if this is handled correctly in django-pushserver even).

@mitar
Copy link
Member Author

mitar commented Nov 13, 2013

Decided not to go for this. Django HTTP interface will be only pure REST. If we need some dynamic one, we could make another HTTP interface with for example Meteor and DDP.

@mitar mitar closed this as completed Nov 13, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant