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. 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/455347ad-689c-49c2-a1c0-ace3127a3583%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
