On Sun, May 31, 2015 at 3:52 AM, Emil Stenström <e...@kth.se> wrote: > Could you help me understand why this have to be done inside a web server > container?
AFAICT, it doesn't have to be done in the container, but currently it must be 'outside' of Django. But having help from the container allows a single request to be passed from one handler (a Django view) to another (the SSE process). it might be easier if you use an URL that goes directly to the SSE process and isn't touched by Django, but then you need some kind of router, or 'outer url dispatcher'. unless the SSE requests can be at a different port from the start? in that case, the SSE process will need its own URL dispatcher. > Also, I don't think you would need to mix redis (or any other persistent > storage) into this. The connected clients could simply be stored in an > in-memory array, that is discarded if the server crashes. When the server is > started again the clients will automatically connect again, and the list of > clients would be built up again. in-memory as a Python object? but i think the SSE handler must be a different interpreter instance... unless it's a thread... not sure if the GIL would be an issue... or an "external" in-memory table? well, that's what Redis is. -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFkDaoSdpgtOheLeyKB_EQAvA5y_peFGCdWNFBZW1xx0XedMTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
