It might be worth supporting sync RSGI applications. This is a long term shot, still unclear if/when it will lands.

At the time of writing, there are 2 possible options for this:

• split RSGI spec into 2 sub-protocols interfaces, eg: RASGI and RSSGI
• implement a dual stack support on existing async interfaces, meaning:
  • HTTPProtocol.__call__ might become sync and the async variant might be moved to HTTPProtocol.__await__
  • HTTPProtocol.__iter__ should be added as a sync variant of HTTPProtocol.__aiter__
  • HTTPProtocol.response_stream should be split into response_stream and response_astream, each of them returning the existing async stream transport or a new sync variant
  • WSProtocol.accept should become an object, where __await__ return the current async transport and __call__ should return a sync transport variant

In both cases there should be a way for the server to know if the application object is an awaitable or not, so probably the advantages of the dual stack approach are narrower than expected as there won't be a handy way for applications to use both interfaces..
Also, in both cases this would be a breaking change, probably requiring a major version upgrade of RSGI protocol.

TBD: pros and cons of the two options, alternative options, feasibility, community interest.