-
Notifications
You must be signed in to change notification settings - Fork 16
Roadmap
A functioning http 1.1 web server
project artifacts. Project langing page, discussion group, CLA policy, readme.md, wiki, roadmap, issue tracking. Purpose these are all good to have, making a project more accessible and inclusive.
https support. Most likely using SslSocket, which uses x509 cert store for server-side certs. Purpose enable you to secure request down to the host, if load balancer of hosting environment itself isn't terminating the https socket and repeating as http socket.
websockets support. Most likely using standard OWIN middleware for actual websocket protocol. Task for server is to ensure the request/response streaming in realtime. Purpose ensure users are not limited in the tech they may choose.
rfc walkthrough. Walk through the http RFC like a bullet list and write a test to verify each of the server SHOULD and MUST statements. Also write a test for each of the server MAY statements, but decide in those tests what behavior the server has chosen to implement. Purpose it's a brute force way of increasing compatability, finding bugs, and producing a regression test harness.
reverse proxy support. [May be added or cut.] Most likely implemented as OWIN middleware or other http proxy app. Task for server is to ensure the request can be flowed efficiently. Purpose enable server to be used as a websockets-capable load balancer.
fastcgi support. [May be added or cut.] Most likely FastCGI would be an additional framing parser type, totally independant of the existing http Frame class. There would be a different server factory call to open fastcgi socket. Purpose enable server to be run behind a load balancer via fastcgi configuration.
wsgi support. [May be added or cut.] Most likely WSGI would be supported as a framing parser type, like FastCGI. Does not imply Python language support - instead the server would translate the WSGI request to an OWIN request for execution. Purpose enable server to be run behind a load balancer via fastcgi configuration.
docs and samples. Shouldn't take much to be honest.
stability work. Create code that will generate as many boundary conditions as possible via socket client. Things like valid requests but send 1 byte at a time, malformed or invalid requests.
performance work. Find one or more web stress harnesses (Apache HTTP server benchmarking tool, ab.exe? Web Capacity Analysis Tool, WCAT.exe?) Find one or more profiling tools (jetbrains dottrace for memory and cpu profiling?)
bug and perf fixes. Other than that, should plan on significant new feature work between Beta and Release
bug fixes. Hopefully none, but there's always a chance you'll need to ship a v1.1 service pack right away.
community support. Answer question. Document how to use server in popular web hosting providers.
continued planning. More of the same for vNext.