Coupling between RSGI and asyncio

[marcuslimdw]

The spec refers explicitly to an asyncio event loop here and here.

Is this intentional? This seems to shut out possible use of anyio and/or trio.

[gi0baro]

Given at the moment Granian is the only server implementation of RSGI, the spec and Granian code are quite tightened.
Granian doesn't support any async implementation other than asyncio, as several parts of its internals interacts or mimic asyncio specific methods or objects.

Personally I have not enough experience with trio to state wether a compatibility layer can be added to Granian in future; it's also unclear to me wether we'll see other RSGI servers popping up in the future. So probably the best approach here is to wait until a server implements support for trio and thus we can update the spec accordingly. Changing the spec before that might led to conditions in which that spec is hard to implement or just badly designed.

[marcuslimdw]

It seems to me that coupling a server specification to a backing async implementation so tightly will 100% mean a (heavily) breaking change in the future, and more or less shuts out anyio and trio users permanently?

note: I have no horse in this race; just want to clarify the intended direction of the project.

[gi0baro]

It seems to me that coupling a server specification to a backing async implementation so tightly will 100% mean a (heavily) breaking change in the future

That's not necessarily an issue. RSGI has a {major}.{minor} version spec, nothing prevents us to issue a new major version of the protocol spec to introduce breaking changes. And I don't see any reason why to be worried right now about it anyways..

and more or less shuts out anyio and trio users permanently?

True. But again: there's no spec/integration facilities for anyio/trio in PyO3 nowadays; nor specific interest into the relevant communities do introduce those.

anyio can be used with Granian/RSGI without any issue, given the underlying impl is using asyncio.
And for the trio compatibility, to me unless a big number of RSGI applications out there (which again, no frameworks provide use for the protocol except for Emmett) start asking for such compatibility, and the relevant involved communities (trio and pyo3) are willing to help on that, I don't see this becoming a priority in the near future. So.. again, why should we worry about this and introduce additional abstraction layers over the protocol today? – which also means we might still need to change those in the future, given the uncertainty.

Does this make sense to you @marcuslimdw?