Withdrawing Channels from 1.10

[Andrew Godwin]

Hi everyone,

I'm going to withdraw the Channels patch for consideration for 1.10; there's a lot more concern and uncertainty around it than I had anticipated, given the reaction up until this point, and it's clear I have some more work to do at convincing the community and proving the design.

Instead, I will take the path-most-trodden for me and large Django features, which is to run it as an external package, compatible with 1.8 through 1.10 (which the package already is), and let it mature and develop outside of core, before coming round to look again at inclusion for 1.11 or 2.0.

My reasons are thus:

 - Trying to push it into 1.10 is either going to delay the release or result in a rush job. We have time-based releases for a reason, and stopping "big-name features" from sinking a release is one of those reasons.

 - There are numerous objections to the design, some well-founded. I'd like to take time to prove out these decisions (or, indeed, refine them) with channels in a more production situation and after a battery of load testing and analysis.

 - Being almost purely an addition to Django, even though it technically inserts a new layer, makes it more well-suited to live externally than many other features. While the external package will have to monkey-patch a few things, it'll be relatively minor.

 - The faster release cycle an external package can bring will almost certainly be useful.

However, the step I'd like to take instead is moving Channels and its associated project repos (daphne, asgiref, asgi_redis, asgi_ipc) under the Django organisation on GitHub and discussing them openly in Django blog posts, documentation and other places as the Django project's official way to get WebSockets working - after all, we are paying people to work on it, and I still remain convinced we need a solution.

I think this is a good mid-step, and given that you would have had to `pip install` extra dependencies to get django.channels to run anyway, no more complicated to use. I'd also propose that these external projects have their own, shorter backwards-compatibility and security guarantees, essentially running on a quicker, lighter version of the main release cycle.

That discussion is upcoming, but I wanted to retract the patch now because I don't want us to get to the 15th May and be unsure about what's going on, and there's plenty of other work we need to do to prep for the alpha.

Sorry about the drama I've stirred up these last few weeks; I had misjudged the situation, and was more confident in the design and code than I maybe should have been. A lot of the goals I want to achieve with Channels can be done as an external package for now, and hopefully it will prove the correct decision to take.

Andrew

[Ryan Hiebert]

Thank you, Andrew, for your hard work. Channels is an exciting new feature, and I'm glad that you're bringing it together. You're doing an excellent job.

[Mark Lavin]

Yes thank you Andrew for your continued work to move this conversation forward. I hope that Channels can continue to grow as an external package under the Django umbrella and bring on more contributors and improvements.

Best,

Mark

[Carl Meyer]

On 05/10/2016 10:39 AM, Andrew Godwin wrote:
> - Being almost purely an addition to Django, even though it technically
> inserts a new layer, makes it more well-suited to live externally than
> many other features. While the external package will have to
> monkey-patch a few things, it'll be relatively minor.

Are there small changes that could be made in Django 1.10 that would
reduce the monkeypatching burden? In the channels repo it seems the only
remaining monkeypatch in hacks.py is for staticfiles' runserver; are
there other monkeypatches I'm missing?

The staticfiles case is a known problem with management command
overriding, and I don't have a good solution. I guess it's a choice
between monkeypatching vs having to document a required ordering of
staticfiles vs channels in INSTALLED_APPS.

Carl

[Tom Christie]

Seems sensible. In particular having the documentation available as part of the regular Django docs would mean there's very little difference to the end user, but without us having to get everything merged into the core codebase. Is the docs element something we can reach a consensus on, or are there any objections to that approach?

[Andrew Godwin]

Yes, that's the main one, and I'll probably leave that in place. There are a couple of fixes I'd like to get in to the sessions objects so it's easier to bring in predefined keys, and untangle BaseHandler a bit, but they're not super important so I'll get them in before the beta if I can; if not, the current approach works well enough.

Andrew 

[Pietro Spagnulo]

Just want to share my emotional support for your astonishing job. God bless you.