Re: My Take on Django Channels

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

Re: My Take on Django Channels

Ryan, Sorry if you felt I was ignoring your reply to focus on the discussion with Andrew. You both made a lot of the same points at about the same time but I did want to touch on a couple things. On Thursday, May 5, 2016 at 4:21:59 PM UTC-4, Ryan Hiebert wrote: > > Thank you, Mark, for starting

Re: My Take on Django Channels

> On May 6, 2016, at 7:21 AM, Mark Lavin wrote: > > Ryan, > > Sorry if you felt I was ignoring your reply to focus on the discussion with > Andrew. You both made a lot of the same points at about the same time but I > did want to touch on a couple things. I totally get it. Focus on the Jedi,

Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Let me just start out saying that I think that ASGI is reasonably designed for the pattern that it is attempting to produce. That being said, I am of the belief that the fundamental way that ASGI is designed to work misses the mark for the kind of feature that people should be using in the general

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Hello Donald, all, Some thoughts inline below. > On 06 May 2016, at 18:11, Donald Stufft wrote: > > For an example, in traditional HTTP servers where you have an open connection > associated with whatever view code you're running whenever the client > disconnects you're given a few options of w

Re: My Take on Django Channels

Hi Andrew, Replying off-list just to say that I totally understand your frustration here, and I wish I weren't contributing to it :( I hope I'm managing to speak my mind without being an asshole about it, and I hope you'd tell me if I failed. Really glad Jacob stepped up on the DEP; I was thinkin

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 10:09 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello Donald, all, > > Some thoughts inline below. > > > On 06 May 2016, at 18:11, Donald Stufft wrote: > > > > For an example, in traditional HTTP servers where you have an open > connection > > asso

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 11:09 AM, Aymeric Augustin wrote: > I think it's important to keep a straightforward WSGI backend in case we crack > this problem and build an async story that depends on asyncio after dropping > support for Python 2. > > I don't think merging channels as it currently stands hinders

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> > ISTM that the strongest argument in favor is that I think it _is_ > significantly easier for a casual user to build and deploy their first > websockets app using Channels than using any other currently-available > approach with Django. Both channels and Django+whatever-async-server > require ma

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Want to just cover a few more things I didn't in my reply to Aymeric. On Fri, May 6, 2016 at 9:11 AM, Donald Stufft wrote: > > > In short, I think that the message bus adds an additional layer of > complexity > that makes everything a bit more complex and complicated for very little > actual > ga

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On May 6, 2016, at 1:45 PM, Andrew Godwin wrote: > > Want to just cover a few more things I didn't in my reply to Aymeric. > > On Fri, May 6, 2016 at 9:11 AM, Donald Stufft > wrote: > > In short, I think that the message bus adds an additional layer of complexity >

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On 06 May 2016, at 19:59, Donald Stufft wrote: > >> On May 6, 2016, at 1:45 PM, Andrew Godwin > > wrote: >> >> On Fri, May 6, 2016 at 9:11 AM, Donald Stufft > > wrote: >> >> So what sort of solution would I personally advocate had I the ti

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On May 6, 2016, at 3:49 PM, Aymeric Augustin > wrote: > > Sure, this works for WSGI, but barring significant changes to Django, it > doesn’t make it convenient to handle WSGI synchronously and WebSockets > asynchronously with the same code base, let alone in the same process. User level co

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On 06 May 2016, at 21:56, Donald Stufft wrote: > >> On May 6, 2016, at 3:49 PM, Aymeric Augustin >> > > wrote: >> >> Sure, this works for WSGI, but barring significant changes to Django, it >> doesn’t make it convenient to handle WSGI synchronously

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 01:56 PM, Donald Stufft wrote: > User level code would not be handling WebSockets asynchronously, that > would be left up to the web server (which would call the user level code > using deferToThread each time a websocket frame comes in). Basically > similar to what’s happening now, e

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 1:19 PM, Carl Meyer wrote: > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > User level code would not be handling WebSockets asynchronously, that > > would be left up to the web server (which would call the user level code > > using deferToThread each time a websocket fra

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > wrote: > > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > User level code would not be handling WebSockets asynchronously, that > > would be left up to the web se

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 2:11 PM, Carl Meyer wrote: > > On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > > wrote: > > > > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > > User level code would not be handling WebSo

Adding dynamic TLD to session cookies to enable subdomain usage

Hi All, First post here, please redirect me where needed if is not appropriate. I wanted to suggest a feature. Our current plan is to use the same Django on subdomain.domain.com and domain.org, and a different Django with CMS on the TLD domain.com We want to enable cookie saving with the TL

Re: re-thinking middleware

I agree with Simon on both counts. We do usually continue to test deprecated code paths until they are removed, but I also think the duplication in cases of tests overriding MIDDLEWARE_CLASSES might not be necessary in _all_ cases; I think some discretion could be used depending on to what extent t