Quantcast
Viewing all articles
Browse latest Browse all 24

Considering ASGI support

@ahopkins wrote:

As I said before, I am reluctant to do this. Having the built in server allows for Sanic to run with one less dependency, makes it extremely simple to get a quick server up and running, and will not break existing deployments. Unless we come across a major obstacle to having more than one interface, my vote is to pursue ASGI support in tandem with the existing embdded server.

There’s not too much going on in Request.__init__. What exactly did you have in mind? Have a couple quick lines of code to help me understand?

This is something that will probably be on the TODO list anyway. There are some ideas floating around for improvements that we can make to the Router, which would of course have an impact in how we handle requests. So, I do not think there is an opposition here. We just would need to of course make sure whatever changes are going to also work for what will be in the works.

Hmmm … This one gives me a little pause because it could impact existing functionality. On the one hand, we could keep the existing listeners for the embedded server, and a new set for ASGI implementation. It does, however create an inconsistency and does not easily allow for developers to switch back and forth. Is this something built into the ASGI standard?

I have no problem with this.

Read full topic


Viewing all articles
Browse latest Browse all 24

Trending Articles