Just to chime in here - I've long been in favour of some kind of support for event-driven stuff inside Django, but as Curtis is saying, there's nothing here that couldn't be done in a third party app first and then proven there before any possible merge into core.
I also don't think that this proposal goes far enough, in a way - any push for a system that allows asychronous calling like this should be available to the request-response cycle as well as websocket/push clients (I want the ability to make my database calls in parallel with my external API calls, perhaps). I have some ideas down this path, but even those are the sort of thing that need a couple of changes to Django to make things work smoothly but the bulk can be implemented outside. If there's specific things Django needs changed to support this properly, I'm all ears, but I'm not sure we should just lump a certain pattern of socket worker in core straight away. Andrew On Mon, Jun 1, 2015 at 12:42 AM, Curtis Maloney <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/django-developers/CAG_XiSCQRorXF-QKvO6GF6Rq3Lf7M29vqdTdjvcgcYKw%2B5tYZg%40mail.gmail.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/CAFwN1upjCFDEZYgQ8kdqU18TtETx9ipwgmMACEZVswWfbrhBYw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
