Closed zostay closed 9 years ago
After some thought, I think this change requires a change to how P6SGI apps are written. They now must become:
sub app(%env, Supply $input) {
start { ... }
}
This is due to the fact that middleware might want to chain into this processing. The neat thing is that it will let middleware do things like, apply encoding, or reorganize the messages to split by WebSocket frames, etc.
Also, I'm thinking that application has a mandate to provide binary bytes through this interface, it is permissible for middleware to process this into other objects: encoding into strings, processing them into custom message objects, etc. I think #3 might benefit from similar considerations in reverse.
I take back what I just said about must. There's no reason why middleware can't do this:
%env<p6sgi.input> .= map(*.decode);
or whatever prior to calling next.
Anyway, this change has been made in the spec now.
I think
p6sgi.input
ought to be a Supply. Proc::Async does this, so why shouldn't we? It would also make a lot of sense for application implementing a WebSocket connection. They can process client frames via a Supply (probably after applying some sort of on mapping to the incoming data to handle frame parsing and such) and output frames to the response Supply they return.