> I don't know if you realize this, but the author, P.J. Eby, is the same guy who wrote the original WSGI spec.
yup (though to conclude anything from that fact is a clear fallacy).
I've realised that what I actually disliked most was his blog-post and not the actual project (I've used identical shims to wsgi-lite by choice over the years).
"CAN'T REPLACE WSGI WITH SOMETHING BETTER? CHALLENGE ACCEPTED"
"WSGI IS DEAD" (Except when it isn't.)
I realise that the above was probably done for facetious editorial reasons rather than his actual intention with the lib. He hasn't really replaced wsgi, he admits should only be used wherever appropriate
Armin uses the async point in part to give technical reasons why WSGI can't really be replaced in full, before concluding that he thinks replacing WSGI for purported notions of pluggable utopia is a red-herring anyway before posing the question of any WSGI replacement: does this really '[make] frameworks work better with each other?'
yup (though to conclude anything from that fact is a clear fallacy).
I've realised that what I actually disliked most was his blog-post and not the actual project (I've used identical shims to wsgi-lite by choice over the years).
"CAN'T REPLACE WSGI WITH SOMETHING BETTER? CHALLENGE ACCEPTED"
"WSGI IS DEAD" (Except when it isn't.)
I realise that the above was probably done for facetious editorial reasons rather than his actual intention with the lib. He hasn't really replaced wsgi, he admits should only be used wherever appropriate
Armin uses the async point in part to give technical reasons why WSGI can't really be replaced in full, before concluding that he thinks replacing WSGI for purported notions of pluggable utopia is a red-herring anyway before posing the question of any WSGI replacement: does this really '[make] frameworks work better with each other?'
I don't think PJ really tackles any of that.