Yes I agree that we do want different things and have different goals. There is nothing wrong with coming to a state of respectful disagreement. I'm glad that some of the feedback could be helpful and I hope it can be incorporated into Channels.
As for a DEP, that would be nice and I'd love to participate in that process. To this point I don't feel like the argument for Channels has been weighed against existing alternative approaches which is largely what I've tried to start here. I mention the DEP process as a source of my own resentment for this change and part of the reason I've held this feedback in for so long. Again I don't think that was fair to you or the Django community to do so. You've been open about your work and your goals. I had plenty of opportunity to voice my concern to you publicly or privately and I chose not to do so for arguably petty reasons. I don't want to see this work blocked because of a lack of DEP if it has the support of the core team and the larger community. I've said my piece about this work and I'm letting those past feelings go so that I can contribute more constructively to this conversation. - Mark On Thursday, May 5, 2016 at 8:52:17 PM UTC-4, Andrew Godwin wrote: > > > > On Thu, May 5, 2016 at 5:13 PM, Mark Lavin <markd...@gmail.com > <javascript:>> wrote: > >> Yes I agree with the value of a standardized way of communicating between >> these processes and I listed that as a highlight of Channels, though it >> quickly shifted into criticism. I think that's where we are crossing paths >> with relation to Kombu/AMQP as well. I find the messaging aspect of >> Channels far more interesting and valuable than ASGI as a larger >> specification. Messaging I do think needs to be network transparent. I just >> don't like that aspect tied into the HTTP handling. At this point I'm not >> sure how to decouple the messaging aspect from the HTTP layer since I feel >> they are very tightly bound in ASGI. >> > > I see what you mean; HTTP is definitely less of a fit to ASGI than > WebSockets, and it wasn't even in there at all initially, but I felt that > the ability to unify everything inside Django to be a consumer was too > strong to pass up (plus the fact that it allowed long-polling HTTP which I > still use a lot in lieu of WebSocket support, mostly for work reasons). > > >> >> Honestly I don't think Django *needs* tightly integrated websocket >> support but I do see the value in it so we aren't at a complete impasse. I >> suppose that's why it's my general preference to see a third-party solution >> gain traction before it's included. I played with integrating Django + >> aiohttp a few months ago. Nothing serious and I wouldn't call it an >> alternate proposal. It's barely a proof of concept: >> https://github.com/mlavin/aiodjango. My general inclination is that >> (insert wild hand waving) >> django.contrib.aiohttp/django.contrib.twisted/django.contrib.tornado would >> be the way forward for Django + websockets without a full scale rewrite of >> the WSGI specification. >> >> > The other track for this was definitely to go the South route and have it > run externally, but based on my previous experience with that route it is > not scalable from a people perspective. > > I personally see this as something where any single third-party solution > is not going to gain enough traction to be tested and tried enough unless > it's defacto recommended by Django itself, at which point it's close to > being a core module with provisional status. > > I feel like we're never going to quite agree on the approach here; I've > explained my stance, you have explained yours, and I think we both have a > good idea where we stand. I agree with some of your concerns, especially > around introducing more moving parts, but then modern websites have so many > already my concerns are perpetually high. > > Given your feedback, I do want to work on a local, cross-process ASGI > backend and write up a full deployment story that uses WSGI servers for > HTTP and Daphne+worker servers for WebSockets, and have it as a top example > for what larger sites should do to deploy WebSockets initially; I think > that's an important piece of communication to show that this is only as > opt-in as you want it to be. > > I'm also hopeful that the introduction of chat, email and other protocol > (e.g. IoT) interface servers to further highlight the flexibility of a > general messaging + worker system will help move us towards a future with > less moving parts; ASGI and Channels was always meant to be something to be > built upon, a basis for making Django more capable in different arenas. > > Your point about the DEP process being circumvented was well made, too, > and I'll do my best from now on to make sure any large project I see being > attempted gets one in sooner rather than later. > > That said, though, I don't know that I can really change Channels in line > with your feedback and still achieve the same goals; we've already come a > long way with it in terms of proving it in real world scenarios and fixing > nasty bugs, and I'm still convinced the core design is sound - we'll take > it to a DEP and run it through the actual process before merge to make sure > that Django is at least on board with that opinion, I owe you that much at > least. > > Andrew > -- 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/7a172a6f-9e1d-4e12-a6d5-c7edff867713%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
