Open jjn1056 opened 8 years ago
that's great idea!
I still need to solicit feedback, but I feel pretty good about the last major change I just made. I intend for it to be the last change (barring any typos or spelling or wording corrections) for the 0.7.Draft. I feel really good about where it is now. I will begin working on my reference implementation in Smack (which I will probably be renaming again before YAPC because I think I have a better name now).
There are a few major differences between what Crust is implementing at the current state of the P6SGI spec (which we may want to rename to avoid confusion with PSGI).
First, it's generally asynchronous. (There is a synchronous mode, which is mainly aimed at supporting legacy applications that would work with Crust or HTTP::Server::Simple/HTTP::Server::Tiny/HTTP::Easy. Though, since each of those implements key bits a little differently, that might be a fruitless aim.)
Second, it provides a mechanism for implementing additional non-HTTP-style protocols within an application (currently, providing a request-response protocol for HTTP, a framed-socket protocol for WebSocket, a psgi protocol for legacy-synchronous apps, and a socket protocol for apps that want to run the server's socket directly to implement custom protocols).
Third, it provides a few new extensions aimed at helping high performance applications keep track of things like connection backpressure (i.e., when the network buffer is backed up because of a network bottleneck between the client and server), detecting connection drops, handling HTTP/2, handling transfer encodings more carefully, and arranging protocol upgrades controlled by the application.
Your feedback is welcome.
Cheers.
And P6SGI has been renamed to P6W because it's nicer to type, simpler, and makes for less confusion with PSGI.
Not sure if you know about https://github.com/zostay/P6SGI but I really wonder if it would be good to get everyone in the same room and work on to good thing together? I point it out because I think the general feeling is if we do something like this for Perl6, the last thing we want is a clone of Perl5 PSGI since that's basically a dead spec that is not forward looking in terms of where web development is going (support for new protocols and web sockets, http2 and all that).
What would ti take to work together?