About context

[Mikael Karlsson]

I like the way the ewgi_context is defined today and I think it should be kept as it is. But there are some issues I would like to bring up.
The reason to carry both he request and the response back and forth through all possible callables is that we want to have a uniform interface and there is no assumption of what a callable is going to do with them.
In practice most of the cases will be that a callable will either rewrite a request or generate/rewrite a response which in turn indicates that half of the information used in the call will never be used.
Now, since Erlang supports dynamic typing and pattern matching we could define the ewgi_context as
ewgi_context() = ReqResp
ReqResp = ewgi_response() | ewgi_request()
ewgi_response() = {ewgi_response,...} etc.
The interface is still "uniform" in a sense.

Now any callable that wants a "GET" request could be implemented as:
handle(#ewgi_response{} = R) -> R; %% Response already created -> return
handle(#ewgi_request{request_method='GET'} = R) ->  %% This is for me
  do_my_stuff_and_return_ewgi_response(R);
handle(#ewgi_request{} = R) ->
  method_not_allowed_response(R).

This would simplify some parts, but it would limit any callable that wants to rewrite a response to only see what is in the previous response. For most cases this is probably enough (like converting to uppercase as in the spec example), but it is a limitation and it makes a pre-assumption of what callables want to do. I can imagine possible applications were you would like to rewrite the response and translate strings to different languages depending on the clients preferred language or perform xml transforms depending upon the capabilities of the client (mobile device/full blown browser etc.) - information that you get from the Request part. So I believe we keep things as they are, but if you think the examples given are exceptional use cases the spec. could be simplified as above.

One thing that could be specified clearly though is how a callable can determine if the response part is empty (not created by any callable prior to itself). As the implementation is made today it is possible to check if the status field has the value 'undefined'. But according to the type declaration it can only be a tuple {integer(),string()}. So either the type declaration is extended to undefined as well or maybe the empty_response() creates a {404,"Not Found"} status header for instance, and this would serve as an indicator that no callable before the current has generated a response, or at least not one with any content.

Best Regards
Mikael

[Filippo Pacini]

IMHO in this way we would complicate writing middlewares and
applications because you always have to write 2 handles: one for the
request and one for the response.
It seems a potential source of errors, for a small gain.

>
> One thing that could be specified clearly though is how a callable can
> determine if the response part is empty (not created by any callable
> prior to itself). As the implementation is made today it is possible to
> check if the status field has the value 'undefined'. But according to
> the type declaration it can only be a tuple {integer(),string()}. So
> either the type declaration is extended to undefined as well or maybe
> the empty_response() creates a {404,"Not Found"} status header for
> instance, and this would serve as an indicator that no callable before
> the current has generated a response, or at least not one with any content.
>

Maybe we might leave handling empty responses to the server gateway:
if the result of the request handle is an empty response than
ewgi_mochiweb (or whatever) can translate it to a 404 response.
And IMHO 'undefined' for the status i a good representation of the empty
response.

best regards,
filippo