ewgi suggestion
Filippo Pacini
Christian made some suggestion for the ewgi interface. I forward his
email here to get some feedback. I think he makes some good points.
Christian's email:
>>>
Hello. I was looking through ewgi to see if I wanted to implement that
callback for ifastcgi (http://github.com/noss/ifastcgi/tree/master). I
postponed doing it because it seemed so straight forward and simple. But
I do think some standard callback interface should be in place.
Something that I do not like about ewgi is that the return values are
specified in the actual values. Something I added to iserve, that
Torbjörn Törnkvist wrote, was to use functions instead of the direct
values.
> From http://github.com/noss/iserve/tree/master/test/iserve_test.erl:
> iserve_request(_C, Req) ->
> error_logger:info_report(
> lists:zip(record_info(fields, req), tl(tuple_to_list(Req)))),
>
> Headers = [{'Content-Type', "text/html"}],
> iserve:reply_ok(Headers, body_ok()).
There are things I like better about this approach:
* using iserve:reply_ok/2 instead of an explicit return value
something like {ok, 200, Headers, Body}
means that I can change the shape of the return term without needing
to change code in callbacks.
* the concept hides more implementation details, such as the
iserve:reply_redirect(Headers, URL) hiding the
specific header to add and the status code in http. "what i want,
not how i want it done". but still allowing you to do whatever you
want with iserve:reply_raw/3
* To me, dialyzer presents clearer results when checking types passed
to functions than types of returned values.
* a badarg will show the actual module iserve:reply_ok was called from
in the stacktrace.
PS
There are a bunch of callback signatures for http requests now.
Mochiweb seem to be the de-facto standard, abusing parameterized
modules.
<<<
End Christian's email
IMHO adding some apis for common responses would be a good idea. What do
you think?
Cheers,
filippo
Hunter Morris
> Hi all,
> Christian made some suggestion for the ewgi interface. I forward his
> email here to get some feedback. I think he makes some good points.
>
> Christian's email:
> >>>
> Hello. I was looking through ewgi to see if I wanted to implement that
> callback for ifastcgi (http://github.com/noss/ifastcgi/tree/master). I
> postponed doing it because it seemed so straight forward and simple. But
> I do think some standard callback interface should be in place.
>
> Something that I do not like about ewgi is that the return values are
> specified in the actual values. Something I added to iserve, that
> Torbjörn Törnkvist wrote, was to use functions instead of the direct
> values.
>
that an API functions like this makes more sense:
iserve:reply_ok(Context, Headers, body_ok())
It is going to have to return a Context tuple ({ewgi_context,...}) in
order to conform with the EWGI spec anyway.
Best,
Hunter
Mikael Karlsson
I think this is a good idea too, for the API implementation. But the EWGI specification - as Hunter points out - should specify the return values explicitly. Maybe a recommendation could be added to the Implementation/Application notes chapter in the specification, that if an implementor would like to be "future proof" for any changes in the ewgi_context it is recommended to use the accessor and return functions provided in the EWGI Reference implementation.
Mikael
Christian
values in terms of what a set of response functions will return?
Treating the return values as opaque types.
Hunter Morris
>
> Can someone explain why it is not a good idea to define the return
> values in terms of what a set of response functions will return?
I hope I'm understanding your question correctly. The main reason is
so that EWGI applications can be chained together easily. A trivial
example:
CtxResult = app3(app2(app1(Ctx)))
The application that you are writing may not return the final value.
The return values are well-defined, not opaque types.
Best,
Hunter
Mikael Karlsson
I guess you could still treat Ctx as an opaque type that any callable accepts and returns, even if you want to chain them together, and that this opaque type is defined through a set of response (and access) functions.
e.g.
Ctx = context()
etc.
I agree that this is a good idea in many ways, and was perhaps somewhat dogmatic when stating that the EWGI specification *should* specify the return values.
Personally I would still like to argue for transparent case though, where you do not hide information, even though this may cause problems for implementors when upgrading the specification.
1. Pattern matching. As the spec is now I can easily pattern match on many fields directly and write clauses for what I want to handle. If the information is hidden I have to use getters and my nice little "one-liners" will be gone.
2. I would like a pure functional approach. Functions and (simple) data structures. No OO-information hiding :-) This gives me as an implementor the freedom to implement things the way I want, (perhaps) at the cost of being more sensitive to future changes.
3. I have come to like the spec as it is now as the record definition really gives the implementor a set of options, you can
3.a access fields through tuple pattern matching, or element(N,ewgi_request)
3.b access fields using records
3.c access field using the API access functions (and creating responses)
3.d write a parameterized module mapping with the same name as the record and use getters and setters or other functions (like in Mochiweb). If you have a record like
-record(ewgi_response, {
status,
headers=[],
message_body,
err
}).
you can write a parameterized module
-module(ewgi_response, [Status, Headers, MessageBody, Err]).
-export([get_status/0])
get_status() -> Status
If you then create a record A=#ewgi_response{status=?OK} you can use it as parameterized module with A:get_status(), as far as I understood it. Kind of a dual nature.
Even if not in the spec. I guess that implementing EWGI API the way Christian propose is far the best for most cases, but for the reasons above I am a bit reluctant to go all the way - not saying it could absolutely not be in the spec. (i.e. I am relaxing my "should" statement, to a "ought to" :-).
Best regards
Mikael
Hunter Morris
> I guess you could still treat Ctx as an opaque type that any callable
> accepts and returns, even if you want to chain them together, and that this
> opaque type is defined through a set of response (and access) functions.
> e.g.
> Ctx = context()
> Resp = context(Ctx, status(ok), Header, Body)
> etc.
> I agree that this is a good idea in many ways, and was perhaps somewhat
> dogmatic when stating that the EWGI specification *should* specify the
> return values.
We have to be careful to separate the EWGI specification and the
sample "API" as given by the ewgi Google code project. The
specification is merely a document which gives implementors a set of
rules to follow. It does not say anything about the API (except
perhaps for "advice") specifically.
> Personally I would still like to argue for transparent case though, where
> you do not hide information, even though this may cause problems for
> implementors when upgrading the specification.
> ...
I am 100% in agreement here. The more transparent the specification
is, the more flexible the implementations can be. I do not expect web
application developers to even really bother with the EWGI spec as
they will be using it through one or more APIs.
> Even if not in the spec. I guess that implementing EWGI API the way
> Christian propose is far the best for most cases, but for the reasons above
> I am a bit reluctant to go all the way - not saying it could absolutely not
> be in the spec. (i.e. I am relaxing my "should" statement, to a "ought to"
> :-).
I think Christian's proposal is a great idea for the API, but we just
have to be careful not to mix the API and the specification too
closely. Do we have any more specific suggestions about changes to
the ewgi_api module?
Best,
Hunter
Mikael Karlsson
Ctx = context()
Resp = context(Ctx, status(ok), Header, Body)
Best regards
Mikael