P6SGI: 4 Myths Dispelled
So my last couple of posts have brought up some grousing from people who do not like PSGI in Perl 5. I am sorry to say that some of this grousing against P6SGI has made some assumptions based on PSGI and not based on P6SGI. I am now going to try to dispel some of these myths.
P6SGI is a direct port of PSGI to Perl 6. If you have started with that assumption, you are wrong. P6SGI is fundamentally different from PSGI in significant ways, mostly in that it is completely asynchronous from the
start: literally, your application must be wrapped in a start-block, which joins a thread.
P6SGI will not do X. This is an early spec. Anything can change right now. Nothing is bolted down for at least 3 to 6 months and nothing is final until 12 to 18 months from now. There is time to make it right. Come contribute. If you want to a commit bit to make your changes, I'm handing them out if you ask nicely.
There is no need for P6SGI/the approach is dead. I beg to differ. I want a P6SGI implementation for myself. Therefore, even if I end up being the only one, there is at least one user that wants it. I am hoping that by engaging the community, I can find other users interested and other use-cases to support.
P6SGI is just re-hashing 15 year old technology. I would rather say that it is improving upon 15 year old technology. P6SGI is asynchronous while most of it's predecessors are not. It will provide tools for streaming input in and out asynchronously without requiring raw access to the socket connection (not totally spec'd, but it will be soon). This is not your father's web gateway.
Seriously folks. We have history with PSGI and WSGI and whatever, but we're not stopping there. Let's get it right this time so that Perl 6 has the implementation everyone is copying for the next 15 years.