P6SGI: Smack the Reference Implementation
The P6SGI standard is progressing reasonably well now. There are a number of issues yet to be worked out it is a reasonably good start. However, before we can really be sure of that, we need an implementation that puts the standard to use and helps us find the warts as well as provides a way to get started working with it.
Introducing: Smack.
Perl has Plack. Perl 6 has Smack. So far, the basics of it's own standalone server are built and working and CGI is started. Some of the built-in apps and some standard middleware have been drafted, but there is a large amount of work to be done.
I have a regular job, 3 boys, and limited spare time. If you have any interest in helping work on the next generation of Perl application servers, your help would be most welcome.
Cheers.
Perl hacker by day, Perl 6 module contributor by night.
Please make sure not to forget all the async cornercases that Perl5's PSGI can't cope with currently. :)
Porting the same tired crap perl5 has to perl6, sweet.
Also, you're*
To me it looks better than having nothing (or CGI, shudder). I haven't tried it yet, though, and my Perl6 is very basic, so I'm not sure I can help...
But thanks for starting something!
LeoNerd, maybe you could post what exactly are the "async cornercases that Perl5's PSGI can't cope with"?
I don't want to be a downer, but its not clear that *sgi type interfaces are a strong path forward. If you look around the general landscape you can see they are not getting updated and people run into trouble properly support web sockets, http2 and a bunch of things. You can sorta make them work but they run into issues like how to handle when a web socket connection breaks, etc. Many of the popular new frameworks are skipping this route and frameworks with bigger communities (like rack with Rails) are really having trouble moving forward on all this.
I have a personal list of PSGI issues are are blocking me working on some Catalyst fixes: https://gist.github.com/jjn1056/a2ca6c0e7cfb2258654d but I doubt that is going to be the full list.
People like Sri (Mojolicious author) seem to feel the approach is dead, and wrote Mojolicious based on that.
Yeah I'd like to see leonerd's list. Part of the problem here is that is feels like the people that are smart enough to know the problems are just not that interested in any sort of PSGI or like.
The question is what are the use cases for P6sgi that we are trying to solve? My guess is that PSGI which is based on WSGI (a spec that is like 15 years old) could use a revisit.
I've spent a ton of time and effort trying to make Catalyst take better advantage of its PSGI bones and at this point the failure of our ability to move PSGI forward is blocking Catalyst from evolving. I wish I had better thoughts here but I really think rather than just port the Perl version we need to really think hard about what the future of this type of system is. Sadly I am not someone who is good to help think that through :(
I have not forgotten, LeoNerd. To summarize, he wants to make sure there is (1) a sensible way for applications to monitor the blocking and hangup ("response backpressure") on the output socket (without necessarily having to have direct access to that socket) and (2) an built-in way for applications to handle Accept-Continue/
Except: 100-continuetype use-cases.Since P6SGI is inherently multithreaded, all servers should be able to handle the requests in such a way that (2) accept-continue use-cases are possible for all applications unless the server's platform inherently prevents it. There are two extensions already provided for handling (1b) connection hangups. I am still thinking about how to handle (1a) blocking on connections.
John, P6SGI is not intended to be a direct port of PSGI. So far, it resembles PSGI, but all applications must be implemented using asynchronous Promises and Supply objects.
I'm reading through your gist regarding PSGI and I will see what I can do to address these issues. Please feel free to file issues against P6SGI on github.
Just a quick response to your concerns:
(1) I think we can require that servers that provide buffering allow for buffering to be disabled. I'm not sure how best to accomplish that, either with your proposed environment or something else. I've considered using traits or something to help with configuration, but such things could be lost with middleware, so I don't think that's the right solution to this problem anyway. I will think about it.
(2) Routing data from server to some other places like S3 sounds very implementation specific. It seems like some middleware to do that is what you want, not a feature of the P6SGI sepc, but please tell me if I'm wrong.
(3) All P6SGI applications are required to return a Promise to avoid blocking the server. Also, all P6SGI applications are required to return a body that is compatible with Supply (i.e., any object that may be coerced into a Supply). This means the server need not block while the application processes the body in its own thread. It also means that applications that don't care about performance and return a List whenever it finishes working, but it still must always do so within a Promise.
(4) I will specify that psgix.io must be an IO::Socket::INET, which is built-in to Perl 6.
(5) There is no streaming, delayed interface. All applications implement the same interface.
So, I think that P6SGI has already gone a long way toward addressing your issues simply because we're talking about Perl 6, which provides concurrency, parallelism, and asynchronous program by definition.
Please give me more feedback. I aim to make P6SGI good for the next 15 years, not the past 15.
By the way, thanks all for the comments. I hope to be giving a talk about P6SGI at the Pittsburgh Perl Workshop, assuming everything works out on my schedule, and you're giving me lots of material to work with.