Re: Channels integration plan, first draft

I have a gut feeling this isn't going to work that well. The reasons include: - Backwards compatibility: how is a large site going to upgrade from 1.9 to 1.10? - Complexity of setup. - Error conditions: for example, what happens when an interface server sends a request to worker, and then die

Re: Decoupling the ORM

I've identified one new "issue". There is an implicit assumption that primary keys are useful for ordering by the current QuerySet API methods `.first()` and `.last()`. I believe the case here is that first and last are meaningless without an ordering, so in lieu of any programmer supplied orde

Re: Channels integration plan, first draft

The problem is that even with a specially named channel you can't guarantee the messages will all go to the same worker so you can re-assemble them on local disk, which kind of makes it still a hard problem. It works for responses because there's only one interface server listening to any response

Re: Channels integration plan, first draft

Hi, To support file uploads or a large message body the http.request message could have an file_channel or body_channel (much like its reply_channel)? These would be something like http.request.file.Dj3Hd9J and would stream chunked file or body content in the same way as the http.response messa

Adding name to fieldsets to improve their validation error text

Right now, if min or max validation doesn't pass on a fieldset, we provide something like the following error : Please submit 1 or more forms. I'd like to propose that we provide a way to generate a slightly mor

Re: Channels integration plan, first draft

Yes, that is the idea. While it obviously adds overhead (a millisecond or two in my first tests), it also adds natural load balancing between workers and then lets us have the same architecture for websockets and normal HTTP. (The interface server does do all the HTTP parsing, so what gets sent ov

Re: Channels integration plan, first draft

Is the idea a large site using classic request-response architecture would get the requests at interface servers, these would then push the HTTP requests through channels to worker processes, which process the message and push the response through the channel backend back to the interface server an

Re: Channels integration plan, first draft

Hi, Am Thu, 17 Dec 2015 12:27:07 -0700 > I'll admit to not being an expert on this use case at all, since I > don't generally do it, but AFAIK SCRIPT_NAME remains pretty key for > transparently deploying a Django site at non-root URL paths. I used this before and can confirm that it is currently

Re: Channels integration plan, first draft

Yeah, I definitely see the need for it, and things like making the webserver transparently change the paths isn't going to work since it can't rewrite output. At least we can rename it and call it request['root_path'] or something. On Thu, Dec 17, 2015 at 7:27 PM, Carl Meyer wrote: > On 12/17/20

Re: Channels integration plan, first draft

On 12/17/2015 11:50 AM, Andrew Godwin wrote: > - I thought SCRIPT_NAME was basically unused by anyone these days, but > hey, happy to be proved wrong. Do we have any usage numbers on it to > know if we'd need it for a new standalone server to implement? It's > really not hard to add it into the req

Re: Channels integration plan, first draft

To address the points so far: - I'm not yet sure whether "traditional" WSGI mode would actually run through the in memory backend or just be plugged in directly to the existing code path; it really depends on how much code would need to be moved around in either case. I'm pretty keen on keeping a

Re: Channels integration plan, first draft

On Thursday, December 17, 2015, Carl Meyer wrote: > Hi Andrew, > - I share Mark's concern about the performance (latency, specifically) > implications for projects that want to keep deploying old-style, given > all the new serialization that would now be in the request path. I think > some furt

Re: Channels integration plan, first draft

On Thursday, December 17, 2015 at 5:50:39 PM UTC+1, Carl Meyer wrote: > > - I share Mark's concern about the performance (latency, specifically) > implications for projects that want to keep deploying old-style, given > all the new serialization that would now be in the request path. > It would

Re: Channels integration plan, first draft

It would be interesting to add a few sentences about file uploads and how they are going to work with the new system. On Thursday, December 17, 2015 at 12:35:18 PM UTC+1, Andrew Godwin wrote: > > Hi everyone, > > One of the first steps I want to get done for Channels is get a rough plan > in pla

Re: Channels integration plan, first draft

Hi Andrew, On 12/17/2015 04:34 AM, Andrew Godwin wrote: > Hi everyone, > > One of the first steps I want to get done for Channels is get a rough > plan in place for how things are going to work in terms of where code > goes, supported versions, etc. I've written up my thoughts on this into > a fi

Re: Channels integration plan, first draft

I have concerns about "built-in feature" means for existing applications (and future applications really). Under "Preserving Simplicty" you note that you should be able to run Django as simply as you do now. Is there a consideration to run "classic" WSGI applications without channels? This in-m

Channels integration plan, first draft

Hi everyone, One of the first steps I want to get done for Channels is get a rough plan in place for how things are going to work in terms of where code goes, supported versions, etc. I've written up my thoughts on this into a first draft of what I'm calling the "integration plan": http://channel

Re: MOSS Award to Django

Hi Samuel, You'll notice if you look carefully that I avoid saying "async" almost anywhere in the Channels announcements or documentation, and when I do, it's qualified very carefully. Channels makes Django event-driven, but it does not provide full "in-process" async like Twisted, asyncio, or som

Re: MOSS Award to Django

I'm uncertain how popular the suggestion will be but ... are "channels" the right solution to our async/concurrency problems? ( I'm all for django-channels the project and the work to solve these issues) All the talk of channels, workers, queues and back ends in the explanations I'm reading as I

Re: Decoupling the ORM

By the time I opened the issue ticket I had become convinced that the DB Compiler was effectively an impossible route. I completely agree with your sentiments about implementing Compiler. I'd go as far as to suggest that few small documentation changes may be warranted in order to suitably expl