Designing for EWGI compatibility

Question

I'm trying to understand how one should design middlewares for EWGI compatibility. Given that there is no EWGI compliant web server yet, I can only ask for your opinion.

If I understand the spec. correctly, a middleware receives an #ewgi_context{} record as input, and returns another record of the same type.

Question is, is the middleware going to be called twice as in django, or is it supposed to call the rest of the middlewares on its own recursively?

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response? (e.g. the file-serving middleware hit a file, so there is no point calling the view middleware). As the result of my view is a context record, how should the rest of the middlewares (or the server) figure out it is the final response?

Answer 1

Hi,

Given that there is no EWGI compliant web server yet, I can only ask for your opinion

There's no need EWGI compliant web server to exist because it's the EWGI's role to unify the access to and from different web server. That's the core idea of EWGI.

On the other hand if you meant "EWGI compliant web framework", there actually are two (or more?) web frameworks that supports EWGI. These are Erlang Web and BeepBeep.

or is it supposed to call the rest of the middlewares on its own recursively?

The middlewares are supposed to call each other in a recursive manner, so it's the middleware's role to decide what to do next.

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response

To answer your last question, I think that because middlewares call each other recursively the simplest way to achieve this would be not to call other middlewares if the answer is final, and return #ewgi_context{} record to the ewgi layer.

Answer 2

Middlewares can use both the iterative or the recursive approach depending on the situation.

An examples of the iterative approach is:

http://groups.google.com/group/ewgi/browse%5Fthread/thread/f9042018cb27baa3

Other simple examples are in ewgi_examples

In general I prefer the iterative approach, but if you you have a middleware that depends on others the recursive approach is probably better.

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response? (e.g. the file-serving middleware hit a file, so there is no point calling the view middleware). As the result of my view is a context record, how should the rest of the middlewares (or the server) figure out it is the final response?

There's no proposed way. Ifyou use the recursive approach as insane answered you only need to return the ewgi_context. In the iterative approach the view, or the view caller, could check to see if the response body and headers are set in the ewgi_context and decide what to do accordingly.

In general I think of ewgi as unix pipes for the web. Each middleware get a request and response (similar to stdin and stdout in pipes) does its job modifying the context (if needed) and returns it.

Hope this helps.