Version 1.0

Introduce App first in README / Docs intro.

• Promote the app = App() style, but then go on to demonstrate plain ASGI style example, and discuss design philosophy of “everything is just ASGI” , interoperable, eg. use TestClient with Channels.

Naming

• WebSocketSession as just WebSocket? Rename session variable as websocket in docs?
• Drop StaticFile, and just leave StaticFiles and FileResponse.
• Module naming - should it be starlette.requests/starlette.responses instead of starlette.request/starlette.response? Would fit websockets and align better with documentation titles.
• App should perhaps be Starlette instead. Less likely to be confused with plain ASGI App class examples, and mirrors eg. flask.Flask and sanic.Sanic.
• Class based views instead as HTTPEndpoint and WebSocketEndpoint?

• Zero-dependencies

Ensure that requests is only required if TestClient is used. Ensure that aiofiles is only required if FileResponse/StaticFiles is used. We could choose to push FileResponse into the starlette.staticfiles module, and only ever import aiofiles from there.

Features

See https://github.com/encode/starlette/milestone/1

• URL Reversing
• Cookies
• Form support
• Class based views
• Exception handling
• Middleware
• StartUp / Shutdown events
• Background tasks

Later

• Server Sent Events
• HTTP/2 (and server push)

[tomchristie]

a request that you keep the ability for Starlette to be utilized as a library toolset

Oh, absolutely! We’ll want the documentation to come from a “here’s how you use a Starlette app” first, and a “here’s the low level stuff” second, but it’s really important that Starlette remains both a framework and a toolkit.

At some point the datastructures ought to get some documentation. Also I’m planning on expanding out concurrency.py with context managers that let you use asyncio timeouts and branching in a more structured way. (ie. Take the lessons from trio, and apply the most important bits. Some of this sort of thing ought to start appearing in Python 3.8 too, but we’d probably like good support for it before that’s widespread.)

[tomchristie]

We have everything that I’d originally wanted for 1.0 support.

The only bit of API that’s giving me any pause on a 1.0 jump is the async bits of requests/websockets. eg. request parsing. Ideally we’d like to eventually be able to use fully sync views too, and still have all functionality available to us. Haven’t yet figured how that’d look for the request/websocket APIs.