FWIW I’m in the same boat as Russell: - limited familiarity with channels: I read the docs cover-to-cover but never ran the code - sufficient trust in their design: I heard Andrew talk about it and I thought it made sense - reasonable confidence that it won’t introduce regressions, including performance regressions (at least with the in-memory backend)
Regarding risks for the 1.10 release, I don’t expect channels to be as problematic as migrations, if only because they’re entirely determined by the current version of the code. In contrast, migrations could be affected by all previous versions of the code, adding a whole new dimension of complexity. Regarding the process, I’m familiar with the situation :-( When I worked on transactions and app-loading, I argued heavily and merged large backwards-incompatible patches at interim steps, just to keep things manageable, under the assumption that I’d manage to figure out a consistent design by the next release. That turned out OK but it was less than satisfying. I tried to improve by getting funding for the “multiple template engines”. A secret goal of that project was to establish a standard of public accountability for funded projects. I received positive feedback on the method — detailed DEP <https://myks.org/en/multiple-template-engines-for-django/dep/>, weekly updates <https://myks.org/en/multiple-template-engines-for-django/> — and I’d love if others adopted it. The topic was nowhere nearly as ambitious as channels, though. Finally I’m interested in hearing more about the “things [Mark doesn’t] like about channels”. Channels has been mostly a solo effort by Andrew. However, until now, public discussion has usually reinforced by trust in his design. We'll see if that trend holds ;-) -- Aymeric. > On 05 May 2016, at 07:53, Mark Lavin <markdla...@gmail.com> wrote: > > Thank you Russ. I'll reconsider expressing my full thoughts on Channels more > likely in another thread. For now I do think it's worth addressing this issue > of benchmarks/performance which keeps being brought up. The argument is that > since this is optional we don't need to see the benchmarks because there > won't be any regressions, which is true. However, if it is also being said > that this is so fundamentally important to Django and everyone will use it so > it cannot live as an external project and must land in 1.10 then I don't > think that argument can be made without ensuring there are no huge > regressions moving an existing application from WSGI to ASGI. If nothing else > those benchmarks seem important for Django users to make an informed choice > about WSGI vs ASGI for their deployment. How can we not care about how this > "fundamental change to Django" might impact performance or say that isn't a > requirement to even measure, regardless of outcome, before its inclusion? > > - Mark > > On Wednesday, May 4, 2016 at 10:00:15 PM UTC-4, Russell Keith-Magee wrote: > Hi Mark, > > On Thu, May 5, 2016 at 8:41 AM, Mark Lavin <markd...@gmail.com <javascript:>> > wrote: > Major features have never been perfect, no, but they have in the past > typically gone through two paths to prove out their design/API/usefulness. > One is as an established and mature third-party app such as messages, > staticfiles, and django-secure. More recently the other has been through the > DEP process: multiple templates (Jinja) and query expressions. Channels has > done neither. > > Sorry if it seems that I've raised these issues late but I don't feel like > there has been a good place for this discussion since the DEP process was > circumvented. Most of the development for this has been in Andrew's space. I > don't feel welcome to raise a dissenting opinion as a mere lowly member of > the Django community. > > If that’s your perception, then we as a community clearly have a problem that > needs to be addressed. > > You’ve been around the Django community since (AFAICT) 2009. You’re a > technical director at a well known and well respected Django consultancy. > You’ve given talks at DjangoCons. You’ve co-written a book about Django for > O’Reilly. If you’re not someone who is in a position to give an informed > opinion on issues with Channels, then I don’t know who is. If you feel like > you’re on the outer and your opinion is not welcome, then that’s *our* > failure, not yours. > > I can’t argue with the fact that the DEP process has been circumvented here. > I also acknowledge that this would be doubly frustrating given your > difficulties shepherding the content negotiation DEP. I don’t think I can > give a good answer for why this has been done, other than enthusiasm and > momentum overriding a not-entirely-well-established process. > > This thread (and email in general) probably isn’t the best place to flesh out > the solution to these process issues, but they definitely need to be > resolved. Discussion at PyCon and DjangoCon US is definitely called for - > I’ll be at both, and I’d definitely be interested in a BOF or similar session > to field opinions and thoughts from the community about this process. > > It's pointless for me to continue to elaborate on the things I don't like > about channels as I'm clearly in the minority and it's going to land. All I > can do now is beg for these requirements to be optional. > > Talking about channels specifically: This shouldn’t be true at all. There’s > certainly some momentum, but the code isn’t in trunk, so it’s not too late. > Even if it *was* in trunk - if you could demonstrate that there was a serious > problem, I’d support removing it from the codebase. > > I will admin that I haven’t been paying *close* attention to Andrew’s work - > I’m aware of the broad strokes, and I’ve skimmed some of the design > discussions, but I haven’t been keeping close tabs on things. From that > (admittedly weak) position, the only counterargument that I’ve heard are > performance concerns. > > However, the last thing I heard on this subject was that the “raw WSGI” path > was essentially unmodified, so there shouldn’t be any particular performance > concerns from adding this to the codebase - just new functionality for > targeting websockets. For me, websockets are a big area where Django is > currently lacking, and everything I’ve read about Andrew’s proposal has > struck me as a reasonable compromise between Django’s need to respond to a > technical requirement, while maintaining ease of implementation. > > I take it that this isn’t your opinion. If you’ve got other concerns - be > they specific implementation issues, or broader philosophical issues, I’d > strongly encourage you to express them. The core team and/or technical board > might not agree with you, but we’d be fools to ignore your experience and > opinions. At the absolute minimum, you’ve earned a considered response to > your concerns. > > Yours, > Russ Magee %-) > > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/455347ad-689c-49c2-a1c0-ace3127a3583%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/455347ad-689c-49c2-a1c0-ace3127a3583%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2E58214D-CFEB-49E7-9086-237F5848512E%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
