To hopefully add to this conversation: I'll start by saying I've enjoyed the contributions by Andrew over the years and believe he is a most excellent developer.
A couple months ago, around the same time that JKM started Andrew's repo (which is what got my attention) I decided to give Channels a try. I had a quick honeymoon with it because I had been working on a game and was using aiohttp. aiohttp provides support for websockets but doesn't manage relationships between them, which makes it hard to do anything without building a layer in between your app and the web. This layer ends up being somethings like Channels. Channels basically accomplished what I needed, which I was ecstatic about. The honeymoon ended when I started using Channels to experiment on my local machine. The notion that I would now have to use a data store to run my app at all didn't feel right, even though I knew there would need to be data stored to maintain relationships between websockets, etc. I was disheartened when I learned Channels was potentially going to be merged into Django, because I finally got to that realization of the fact that there wasn't a "right way" to include baked-in web sockets behind a web server, only to find out that Channels was going to be called the "right way", forever (potentially). So, let me ask a question: how many of the past 5 paid projects you worked on required websockets? For me, and for most of the people I know (not many), the answer is 0. I can think of a use case where it would have been nice (the "how many other users are viewing this page" feature, which we accomplished with slow Ajax polling), but I can think of nothing critical. I ask that question because a good argument came up earlier, a comparison to NoSQL. NoSQL was in the same must-have craze, and then the tried and true standard in Django (Postgres) sort of answered that with huge gains in performance and scalability. Competition is great for this reason, but merging in competion is sort of like a business acquiring innovative. competitors as they emerge; it doesn't do much to further the company's true vision, because it's a defensive move. I would recommend against merging Channels now, and potentially ever; not because it's not great code, but because A) it isn't necessary for the core, B) leaving it out of the core doesn't prevent it from being used, and C) it should be proven over time as an outside package (a different way of solving this could come by and proliferate while we have Channels in core, and then Django would be heading back down that hill towards the bloat (e.g., contrib) it worked so hard to remove over the years - not that Django was ever *truly* bloated). What I would recommend is that we focus on fixing/abstracting/documenting things that make it hard to integrate something like Channels (e.g., things that Andrew has to monkey patch, etc.), because Channels *and* a hypothetical future websockets package could both take advantage of such an abstraction layer. Political tirade follows: Another thing I would never recommend is letting a grant destroy Django's ability to make a decision on its own. It absolutely disgusts me to think of Django becoming like Firefox, with "features" like Pocket and Hello that are driven by financial or political desires. Django should continue to look unemotionally at feature requests without regard for sunk cost fallacy (e.g., "<developer> already spent X time working on this...", etc.). -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bcbbf085-a11c-4894-a599-aa7867899e71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
