Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the change that broke Django and issue 3.2.9. Andrew On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote: > Ok, so rebasing PRs to current master will fix this (leaving this here as > note for others who run into

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Ok, so rebasing PRs to current master will fix this (leaving this here as note for others who run into this). On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote: > > It's an issue with the asgiref==3.2.8, see > https://github.com/django/asgiref/issues/170. We temporarily

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

It's an issue with the asgiref==3.2.8, see https://github.com/django/asgiref/issues/170. We temporarily pinned asgiref==3.2.7 [1]. Best, Mariusz [1] https://github.com/django/django/commit/dcb4d79ef719d824431a8b3ff8ada879bbab21cc -- You received this message because you are subscribed to

What's wrong with the jenkins testrun failing on ASGI (I think?)

Hi, do we have any idea what is happening on https://djangoci.com/job/pr-mariadb/database=mysql,label=mariadb,python=python3.8/6459/ ? It seems as if (mostly) the same set of tests is failing over and over. Is this ASGI/concurrency related? Cheers, Florian -- You received this message

Re: Django 3.0 Release Notes - ASGI

:46 UTC+11, Andrew Godwin wrote: > > I agree - we need to communicate that ASGI support does *not *mean you > can start writing async def views. I think we should put a big disclaimer > to that effect next to it in the release notes and say it should be coming > next rele

Re: Django 3.0 Release Notes - ASGI

I agree - we need to communicate that ASGI support does *not *mean you can start writing async def views. I think we should put a big disclaimer to that effect next to it in the release notes and say it should be coming next release. Andrew On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton wrote

Re: Django 3.0 Release Notes - ASGI

Good point, Josh. I think we should either add an "experimental" note to the ASGI notes or introduce an "Experimental changes" section (I'm open to other naming suggestions) /Markus On Tue, Oct 15, 2019, at 9:45 AM, Josh Smeaton wrote: > A co-worker jus

Django 3.0 Release Notes - ASGI

A co-worker just linked me to https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and asked me (basically) if we can start doing all kinds of async work in one of our projects. Unfortunately, I didn't really know how to answer. Preface: I haven't followed the ASGI plan very

Re: First ASGI pull request is ready for review

This is quite unrelated to frontend - I'll explain more of the impact and potential impact in the DEP when I write it up. Andrew On Wed, 1 May 2019, 08:30 Elad Yaniv, wrote: > Exciting stuff! > does this mean that django 3.0 COULD compete with frontend js frameworks > ? (angular react vue) >

Re: First ASGI pull request is ready for review

Exciting stuff! does this mean that django 3.0 COULD compete with frontend js frameworks ? (angular react vue) if the answer is yes i will be a very happy developer Great work! Elad. On Wed, May 1, 2019 at 9:55 AM Carlton Gibson wrote: > Yes, I’ll review properly first half of next week. >

Re: First ASGI pull request is ready for review

Yes, I’ll review properly first half of next week. For the DEP, can you break out how and where people might input. There’s massive interest.  Great work as ever Andrew. Thank you so much! C. On Wed, 1 May 2019 at 08:46, Andrew Godwin wrote: > > > On Tue, Apr 30, 2019 at 11:34 PM Mariusz

Re: First ASGI pull request is ready for review

On Tue, Apr 30, 2019 at 11:34 PM Mariusz Felisiak < felisiak.mari...@gmail.com> wrote: > Thanks for this patch. Can you add a trac ticket? also Can you give me & > Carlton few days for review? I should be able to do this somewhere in the > next week. > I can indeed. I wasn't sure if you wanted

Re: First ASGI pull request is ready for review

Thanks for this patch. Can you add a trac ticket? also Can you give me & Carlton few days for review? I should be able to do this somewhere in the next week. Are we going to create "Async" DEP? Best, Mariusz -- You received this message because you are subscribed to the Google Groups

Re: First ASGI pull request is ready for review

d to drop a note and say that the first pull request in the > series needed to enable async in Django is now ready for review: > https://github.com/django/django/pull/11209 > > This is a very minimal amount of work to get Django async-safe and > understanding ASGI as an application

Re: First ASGI pull request is ready for review

: https://github.com/django/django/pull/11209 This is a very minimal amount of work to get Django async-safe and understanding ASGI as an application interface, but the idea is to land this so it's definitely in 3.0, and then work on getting async abilities down to views before the 3.0 feature

First ASGI pull request is ready for review

Hi everyone, Just wanted to drop a note and say that the first pull request in the series needed to enable async in Django is now ready for review: https://github.com/django/django/pull/11209 This is a very minimal amount of work to get Django async-safe and understanding ASGI as an application

Re: Rethinking ASGI & Channels

On Fri, Jul 21, 2017 at 4:10 AM, Tom Christie wrote: > Hi Andrew, > > Thanks for writing that up so comprehensively! > > Definitely in favor of moving to a server:consumer interface - as you say > that doesn't preclude over-the-network from being one of the possible >

Re: Rethinking ASGI & Channels

Hi Tom, I want to experiment with a uvicorn approach. I planning to do some after PoC of worker separation from channels. I will let you know if I have some questions. **Probably** Channels as a library will be a first user of the suggested interface of the uvicorn. Regards, Artem. On Fri, Jul

Re: Rethinking ASGI & Channels

Hi Andrew, Thanks for writing that up so comprehensively! Definitely in favor of moving to a server:consumer interface - as you say that doesn't preclude over-the-network from being one of the possible deployment styles. I like your proposed approach to async vs sync variants of the

Re: Rethinking ASGI & Channels

blocking receive constantly. >> >> Probably this design shift will feet 2.0 release. >> >> I'll try to implement it in the separate channels branch after PyCon >> Russia 2017. >> >> >> On Wednesday, July 12, 2017 at 2:25:27 PM UTC+3, Andrew Godw

Re: Rethinking ASGI & Channels

stantly. > > Probably this design shift will feet 2.0 release. > > I'll try to implement it in the separate channels branch after PyCon > Russia 2017. > > > On Wednesday, July 12, 2017 at 2:25:27 PM UTC+3, Andrew Godwin wrote: >> >> Hi all, >> >> After

Re: Rethinking ASGI & Channels

; > After recent threads on ASGI and similar problems ( > https://groups.google.com/forum/#!topic/django-developers/_314PGl3Ao0), > and my own introspection about where we are almost two years in, there are > some changes I would like to make to the overall way ASGI/Channels works, > bo

Rethinking ASGI & Channels

Hi all, After recent threads on ASGI and similar problems ( https://groups.google.com/forum/#!topic/django-developers/_314PGl3Ao0), and my own introspection about where we are almost two years in, there are some changes I would like to make to the overall way ASGI/Channels works, both to make

Re: On ASGI...

Raising this across in aio-libs for a bit of exploratory discussion... https://groups.google.com/forum/#!topic/aio-libs/7rJ8Pb1y7aA > I'm not sure where I sit on it - on one hand <...> on the other hand <...> Same really, yes. :) -- You received this message because you are subscribed to the

Re: On ASGI...

> > > > If we end up with one format for channel names and messages that is > spread across two consumption forms (in-process async and cross-process > channel layers), I think that would still be a useful enough standard and > make a lot more people happy. > > Yes. I'm not sure if there aren't

Re: On ASGI...

> My ideal solution is one that allows both approaches, and I'd like to investigate that further. I think you're getting closer to the sort of thing I'm imagining with the uvcorn designs, but I feel like there's still something a little extra that could be done so it's possible to offload over

Re: On ASGI...

FuncName() and FuncNameAsync() are common patterns in .NET land with async/await. The snake case translation would be funcname_async. From a quick scan, the JS world hasn't settled on a convention yet, though there is a bit of discussion about how to differentiate the names. Personally I don't

Re: On ASGI...

Right - as long as you make clients deal with reconnection (which obviously they should), then as long as your load-balancing has a way to shed connections from a sticky server by closing them then all should be fine. Honestly, I have always been annoyed at the no-local-context thing in channels;

Re: On ASGI...

> I wonder if there is a way of doing something like this well, so that it's easy to write but also lets you scale later. It's not obvious that sticky websockets are *necessarily* problematic for typically use cases. Couple of things you'd want: * Have clients be responsible for graceful

Re: On ASGI...

Ah, I see, you are assuming sticky sockets. That makes things a lot easier to architecture, but a whole lot harder to load-balance (you have to get your load-balancer to deliberately close sockets when a server is overloaded as many will not go away by themselves). Still, it makes scaling down a

Re: On ASGI...

> I note that your examples do not include "receiving messages from a WebSocket and sending replies" - I would love to see how you propose to tackle this given your current API, and I think it's the missing piece of what I understand. I've just added an `echo` WebSocket example. I've also now

Re: On ASGI...

ething like that as part of > the ASGI spec? > I had been pondering doing so for a while and I think this thread has catalysed me to actually do it (and incorporate support for it into the Channels/asgiref stuff too, so everything can use a common Worker class if it's running in a separate proce

Re: On ASGI...

> def handler(channel_layer, channel_name, message): Oh great! That's not a million miles away from what I'm working towards on my side. Are you planning to eventually introduce something like that as part of the ASGI spec? > So is the channels object just a place to stuff different fu

Re: On ASGI...

interface, blocking send/receive interface) > asyncio (coroutine interface, coroutine send/receive interface) > > Presumably the equivalent would be true of eg. twisted. > > (There's a couple of diff things you can do to bridge from the asyncio > interface -> sync interface if th

Re: On ASGI...

Figure I may as well show the sort of thing I'm thinking wrt. a more constrained consumer callable interface... * A callable, taking two arguments, 'message' & 'channels' * Message being JSON-serializable python primitives. * Channels being a dictionary of str:channel * Channel instances expose

Re: On ASGI...

able, then the server should buffer the incoming data > and only dispatch a single message. (Not a problem wrt. Django, since > ASGIHandler ends up effectively doing that in any case.) > > Right, and this is the ultimate tradeoff I had to make in ASGI - the WebSocket design problem means you s

Re: On ASGI...

> Any interface like this would literally just be "this function gets called with every event, but you can't listen for events on your own" Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, since the channel reader would be a coroutine. Which makes for interesting design

Re: On ASGI...

mer interface is part of the channels API reference, > rather than part of the ASGI spec. > Is the plan to eventually include the consumer interface as part of the > ASGI spec, and make it more clearly separate to channels? > No, consumers as they are in Channels right now I s

Re: On ASGI...

Making some more progress - https://github.com/tomchristie/uvicorn I'll look into adding streaming HTTP request bodies next, and then into adding a websocket protocol. I see that the consumer interface is part of the channels API reference, rather than part of the ASGI spec. Is the plan

Re: On ASGI...

ing ASGIHandler. (And yeah, I see > that you'd be adding channel queues at that point.) ayncio.Queue is looking > like a mightily useful bit of tooling right now. > > > the design of an ASGI-direct protocol > > I think the important part of this is "how does asyncio code look in the

Re: On ASGI...

ily useful bit of tooling right now. > the design of an ASGI-direct protocol I think the important part of this is "how does asyncio code look in the context of an ASGI consumer interface" rather than specifics about server-direct-to-consumer configurations. Not unreasonable that

Re: On ASGI...

Thanks for the continued speedy research, Tom! Weighing in on the design of an ASGI-direct protocol, the main issue I've had at this point is not HTTP (as there's a single request message and the body stuff could be massaged in somehow), but WebSocket, where you have separate "connect"

On ASGI...

I've been doing some initial work on a Gunicorn worker process that interfaces with an ASGI consumer callable, rather than a WSGI callable. https://github.com/tomchristie/asgiworker In the standard channels setup, the application is run behind a message bus... Protocol Server

Re: Changing how Channels/ASGI receives messages

On Tue, Mar 28, 2017 at 10:39 AM, Oskar Hahn <m...@oshahn.de> wrote: > Hi, > > I am not sure, if I understand your proposal correctly. Do you mean, the > asgi server has to listen only to one channel or do you mean it has to > listen to one channel of any channel-type? &g

Re: Changing how Channels/ASGI receives messages

Hi, I am not sure, if I understand your proposal correctly. Do you mean, the asgi server has to listen only to one channel or do you mean it has to listen to one channel of any channel-type? So with redis, do I have to call "BLPOP LOCALID TIMEOUT" or do I have to ca

Re: Changing how Channels/ASGI receives messages

I have added that in to the spec: http://channels.readthedocs.io/en/latest/asgi.html#capacity Andrew On Tue, Mar 28, 2017 at 9:54 AM, Artem Malyshev wrote: > Yes, I saw your changes after I wrote my previous email. > > Global capacity for process sounds reasonable.

Re: Changing how Channels/ASGI receives messages

Yes, I saw your changes after I wrote my previous email. Global capacity for process sounds reasonable. Probably we should state it in spec. Regards, Artem. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Changing how Channels/ASGI receives messages

On Tue, Mar 28, 2017 at 6:27 AM, Artem Malyshev wrote: > Hi everyone, > > It can be huge improvement for asgi_rabbitmq layer. But I'm asking > you to keep this change in the experimental branch before I implement > it for RabbitMQ layer. More questions can came up in

Changing how Channels/ASGI receives messages

Hi everyone, It can be huge improvement for asgi_rabbitmq layer. But I'm asking you to keep this change in the experimental branch before I implement it for RabbitMQ layer. More questions can came up in progress. For me it is still unclear how to implement `channels_capacity` option for

Re: Changing how Channels/ASGI receives messages

That sounds like a massive improvement and goes in line with the issues I've observed. On Tuesday, March 28, 2017 at 3:51:20 AM UTC+2, Andrew Godwin wrote: > > Hi all, > > I wanted to ask your feedback on a proposed change I want to make to the > ASGI spec for channel layers. &g

Changing how Channels/ASGI receives messages

Hi all, I wanted to ask your feedback on a proposed change I want to make to the ASGI spec for channel layers. In particular, my goal is to make it so that Daphne only has to receive() on a single channel at any time, massively simplifying the work it takes to poll for new messages

Re: Will asgi become a PEP like wsgi is ?

re useable by anything (I need to look into getting another framework like Flask working on top of it as a proof of concept). My main sticking point is the design of the ASGI messaging interface, as that will be the one thing that everyone has to write against - are the number of calls we have enough?

Re: Gevent based ASGI server

to the main asgi_redis transport? It would improve performance on asyncio or twisted as well. Andrew On Sun, Mar 12, 2017 at 9:54 PM, Jon Pry <jon...@gmail.com> wrote: > I modified Daphne and the ASGI layer to get the one of the examples to run > under gevent. > > Code is here: >

Re: Will asgi become a PEP like wsgi is ?

As far I know Django channels is a Django framework enforcing a specific messaging protocol in mind. I don't see how implementing ASGI could help to build more scalable apps without breaking compatibility with WSGI. E Le 2017-03-13 à 07:50, James Pic a écrit : On Mon, Mar 13, 2017 at 12

Gevent based ASGI server

I modified Daphne and the ASGI layer to get the one of the examples to run under gevent. Code is here: https://github.com/jonpry/thyme Code is not as clean as it needs to be. But imho it works better than daphne, none of this hot polling stuff going on anymore. In any case it's interesting

Re: Will asgi become a PEP like wsgi is ?

WSGI is for building web applications in Python. ASGI is for building platform-oriented web applications in Django. I'm -1 on this. I prefer the ease and flexibility of WSGI draft over asynchronous platform choices. E Le 2017-03-13 à 07:08, James Pic a écrit : I do not see myself using

Re: Will asgi become a PEP like wsgi is ?

it only does plain HTTP/1.1. It cannot handle quite a few features of HTTP/2, and provides no support whatsoever for modern bidirectional web protocols like WebSocket. ASGI attempts to fill that gap by defining a protocol which allows these other protocols/features to communicate with Python

Re: Will asgi become a PEP like wsgi is ?

On Mon, Mar 13, 2017 at 12:58 PM, Etienne Robillard <tkad...@yandex.com> wrote: > > As far I know Django channels is a Django framework enforcing a specific > messaging protocol in mind. Honnestly I thought the messaging protocol was just msgpack. > I don't see how implementi

Re: Will asgi become a PEP like wsgi is ?

On Mon, Mar 13, 2017 at 12:26 PM, Etienne Robillard <tkad...@yandex.com> wrote: > ASGI is for building platform-oriented web applications in Django. Could you elaborate on this ? The only mention of Django I found in the spec linked by the OT is "Django Channels ships with a

Re: Will asgi become a PEP like wsgi is ?

I do not see myself using Django without Channels anymore, it's become a basic Django feature for me and I just love it. Despite my perhaps lack of knowledge about the protocol internals, such features seem like it would certainly benefit the Python community and anyway I'd say it's worth a try

Re: Will asgi become a PEP like wsgi is ?

Hi Sebastian, The proposal is certainly written like a PEP, and that is somewhat on purpose, but the scope and need for it are still a bit up in the air. In particular, ASGI currently specifies two parts: - An interface for talking to channel-based message queues and a set of guarantees and non

Will asgi become a PEP like wsgi is ?

(sorry for cross-posting - post should like be here rather than in django-users) Hi, wsgi is specified by PEP 333 -- Python Web Server Gateway Interface v1.0 https://www.python.org/dev/peps/pep-0333/ Django channels rely on asgi instead. So far ASGI specs appear only here: http

Re: Django Channel asgi specs - question on how to handle a websocket connection

Thanks. I updated my code accordingly. But I open the websocket connection after one second if the python application does not send an Send/Close/Accept message. In other case the software would not be compatible with the examples in https://github.com/andrewgodwin/channels-examples I uploaded

Re: Django Channel asgi specs - question on how to handle a websocket connection

On Mon, Jan 2, 2017 at 1:10 PM, Oskar Hahn <m...@oshahn.de> wrote: > Hi, > > this is a question on how to interpret the asgi specs of django channels: > > https://channels.readthedocs.io/en/latest/asgi.html > > If this is the wrong place to discuss it, then please po

Django Channel asgi specs - question on how to handle a websocket connection

Hi, this is a question on how to interpret the asgi specs of django channels: https://channels.readthedocs.io/en/latest/asgi.html If this is the wrong place to discuss it, then please point me to the right place. I used some free time to learn the language "go" and tried to write

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

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

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,

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 >>

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

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

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

what you can do, but the most common > option in my experience is that once the connection has been lost the HTTP > server cancels the execution of whatever view code it had been running [1]. > This allows a single process to serve more by shedding the load of connections > that

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

had been running [1]. > This allows a single process to serve more by shedding the load of > connections > that have since been disconnected for some reason, however in ASGI since > there's no way to remove an item from the queue or cancel it once it has > begun > to be processed

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

lost the > HTTP > > server cancels the execution of whatever view code it had been running > [1]. > > This allows a single process to serve more by shedding the load of > connections > > that have since been disconnected for some reason, however in ASGI since > > t

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

edding the load of connections > that have since been disconnected for some reason, however in ASGI since > there's no way to remove an item from the queue or cancel it once it has begun > to be processed by a worker proccess you lose out on this ability to shed the > load of processing a

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