I think the real questions are: 1. What is stopping a 3rd party product from providing the features you want?
If there is something Django can do to make it easier, point it out, and I'll gladly champion a good feature. 2. Why should your solution be the "blessed" solution? The discussion clearly shows there are several ways to skin this cat... why is your way better than any other? Until there is a clear winner [see migrations and South] it should live as a 3rd party app, with Django providing whatever mechanisms/support it can. Personally, I've used DOM-SSE to implement a simple chat service in Django, using Redis for the PUB-SUB server. It was only really feasible because (a) I used gevent, (b) no ORM means no need for async DB adapter, and (c) the py-redis module is Pure Python, so can be monkey patched. [FYI I've also translated that same code to raw WSGI app, and using async-io, available on github if you're interested </shameless-plug>] -- Curtis On 1 June 2015 at 08:03, Emil Stenström <[email protected]> wrote: > On Sunday, 31 May 2015 15:56:09 UTC+2, Florian Apolloner wrote: >> >> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote: >>> >>> Client A clicks a button on the site, that sends an normal ajax request >>> to Django. In the view a message is passed from Django to the SSE process. >>> >> >> How, you still need some kind of interprocess communication >> > > Yes, interprocess communication is needed. The simplest way to get the two > programs to talk would be to use a HTTP POST to the other program (which > would run on another port). This would also make it possible for other > programs to send messages through the same connection. > > >> So the SSE process is VERY simple. It just connects to clients and passes >>> on messages the all clients connected. >>> >> VERY simple is an oversimplification in my opinion. I also do not see any >> reason for supporting it inside Django currently when things like >> autobahn.ws >> <http://www.google.com/url?q=http%3A%2F%2Fautobahn.ws&sa=D&sntz=1&usg=AFQjCNGXKWrHf12kYQWhypSwU402DKsGnw> >> exist, the only thing missing there is the communication between the >> processes. >> > > Is the argument here that "since there are other ways of doing it I see no > reason to do it in Django?". Autobahn is a huge dependency on your program, > when all you need for most usecases is a small event loop and a way to pass > messages. Setting up websockets and redis pubsub is also a huge hassle. I > see the need for something simple, something you could get up and running > quickly. > > >> I am not sure what people are expecting here from Django (and from your >> explanations I am still not really convinced or see a usecase at all). >> > > A simple use-case is Facebook style notifications. When something happens > to a user you want to send that user a notification right away, not 10 > seconds later because that's how often you were polling the server. Another > use-case is a user chat. When a user sends a message you want that message > to show up right away. Or maybe you keep track of server uptime on a status > page. When a server goes down you want your users to be notified > immediately, not later. > > >> Since the message passing between the server processes should be >> language/framework agnostic anyways, this would be better suited for a >> third party project anyways. Reimplementing one of the existing >> SSE/Websockets implementations does not really seem like a win to me either. >> > > I agree that they should be language/framework agnostic, that's why I > think a HTTP Post would work great to send messages. And I agree this could > be developed as a separate project to start with. I *don't* agree that > this wouldn't be something worthwhile to include in Django. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/d1148851-7ced-4463-9bf5-02a54d5a5ade%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/d1148851-7ced-4463-9bf5-02a54d5a5ade%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAG_XiSCQRorXF-QKvO6GF6Rq3Lf7M29vqdTdjvcgcYKw%2B5tYZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
