Hi Emil, I agree that there perhaps needs to be a more "pull" here than just making a third party app, but I feel I can speak from a good place when I say third party apps can absolutely prove core Django features in a way that gives them much faster release cycles and freedom from things like LTS commitments initially, so they can be rapidly improved upon before being deemed worth merging. The alternative is either merging something into core that's not ready, dooming it to a slow release cycle and perhaps community pushback, or developing it as a parallel branch which is not something that's going to be long-term sustainable.
This problem has been something I've been wanting to tackle for a while now - I've always felt that the next step for Django is to start moving away from being so married to the request-response cycle of traditional HTTP - and I've been formulating a plan over the last few months about how to tackle it. It's relatively ambitious, but I think entirely achievable and would be almost completely backwards-compatible. Unfortunately, it's taken a while to get over the 1.7 release cycle and migrations work being slightly overwhelming, or it would have been sooner. I'm sounding out some of the ideas here at DjangoCon Europe, and hopefully come to the list with an initial proposal or implementation soon - I think the best way to approach this is to sit down and design the API and core code architecture, start proving it's possible, and then present that, because in my experience having code examples can really make a proposal a lot easier to understand. Of course, I'm also fully prepared for people to shoot down my ideas - being a core team member doesn't give me some magical ability to push through changes. Andrew On Mon, Jun 1, 2015 at 11:11 PM, Emil Stenström <e...@kth.se> wrote: > Thanks for you reply Andrew, > > On Monday, 1 June 2015 13:05:34 UTC+2, Andrew Godwin wrote: >> >> 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. >> > > That seems to be the argument for all my three suggestions: Build it as a > third party app, and if you get everyone using your three apps we might > consider adding them to Django. I was hoping for a more "product driven" > approach, where we look at the world around us, see that Django is lagging > behind in a major area for modern apps, and start playing around with > different ways of tackling the problem. Given that there are people that > agree this is a problem for Django, I was hoping for more of a "pull" from > the community. "We want something that solves this problem, this way, > without doing this". > > 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. >> > > I agree that this would be great, but given that Django won't be rewritten > to support async everything any time soon I think this will be a far to big > first step. In my experience, starting small and iterating is a much better > way to get great things going. And my subset of server->client message > passing is just that. > > 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. >> > > "Lumping something in" is not something in is not something I've > suggested. I'm fully prepared that this will take time and effort. > > -- > 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/4bbf9e68-b1b8-4701-bca7-eb062626e94b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4bbf9e68-b1b8-4701-bca7-eb062626e94b%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 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/CAFwN1urSpH%2BS9xa4TofskfKMdw-pP0__oARaiz94-hzHwMJQpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
