RB2.0 branch ready for merge

[Hunter Morris]

I believe the RB2.0 branch is ready to be merged into trunk. I have
made the revisions we talked about earlier both to the specification
and the reference implementations. Please take a look at my changes
and let me know if there are any additional concerns which I may have
missed.

Thanks for all the feedback so far! I feel like this project has legs
again.

Best,
Hunter

[Filippo Pacini]

Great Hunter!

I'll take a look this evening to fix the tests so we have some working
examples before merging the changes :-)

Another couple of things:
1. I'd like to switch to erlware.
There might be some issues with testing, but we could leave a make test
around for a while.
2. (low priority) Now that middleware and applications have the same
interface we might talk in general about components (or maybe filters a
la unix) instead of making the distinction. What we have is like pipes
in unix: a way to components.

What do you think?

[Torbjorn Tornkvist]

Hi,

Sorry, but I haven't had time to look into this (yet), but
I just want to mention that 'dart' in erlware is using ewgi.
So any changes to the API will probably affect me.

--Tobbe

[Mikael Karlsson]

Agree, great job!

I have some thoughts about Error handling. Would it be of interest that the API handles throw(EwgiContext) from any callable? In this way any "component" could throw an error, or break out with any other response. For instance an authentication module may rewrite the request and fill in the auth_type and remote_user* fields in the return value if it succeeds but throw an {401,"Unauthorized"} response (with WWW-authenticate headers) if it needs an authorization or if it fails. The other option is not to throw but to put the response into the return value - but that means that any other component coming next needs to be aware of this condition, and not proceed with its own stuff in case status code differs from 200 for instance. Or did you have something special in mind with the err field in the ewgi_response record?

Agree that talking about components is very suitable. Components are similar to filters/pipes but I think that you may also organize them in other ways - dispatchers for instance?

Best regards
Mikael

2008/10/22 Filippo Pacini <filippo...@gmail.com>