RSGI Motivation about granian

[gi0baro]

@b4stien would you give your opinion on #60 ? Thanks in advance :)

[b4stien]

Sorry for the very late reply, answering here instead of in the PR._

Thanks for the explanation! I'm not sure I understand the rational yet, here are some pointers about what could help.

• Reasoning from first principles, it's not clear for me what problem in the "ASGI world" the "RSGI world" answers. Could you add precise examples of what is not possible without and what becomes possible with RSGI? For instance, I'm no expert in ASGI spec, but it's split into two part, the "protocol server" and the "application". Is the RSGI need coming from the "protocol server" being mandatorily written in Python? (for the record, uvicorn is written with Cython, which is not strictly Python)
  • You mention a "double await" being imposed in ASGI in a discussion, maybe it's a good starting point?
• In particular you describe as "problem" various points which do not strike as problematic for the first time reader, for instance ASGI being tied to Python sounds OK: at the end of the day we are writing Python apps. On the same sentence: is ASGI really tied to asyncio? There are some ASGI servers written without asyncio (with trio for instance). If I miss something and these are real problems I think you could explain them more.

As a pure opinion (and I beg you to take it for what is is, an opinion): 1. there are a ton of WSGI/ASGI projects in production right now, 2. the ecosystem needs a down-to-earth-simple and high performance server for those projects, unencumbered with decades of legacy, 3. granian looks like the perfect project for this. I suspect you'll see a stream of ASGI/WSGI invested users being VERY interested in ASGI/WSGI support and not much by RSGI. At the end of the day you decide where you want to lead your project.