[erlang-questions] Thoughts on EHE - the PHP killer

[Steve Vinoski]

On Mon, Feb 20, 2012 at 12:13 PM, Tim Watson <watson.timothy@REDACTED> wrote:
> On 20 February 2012 12:23, Steve Vinoski <vinoski@REDACTED> wrote:
>>
>> There's really nothing like servlet filters. I guess the closest thing
>> -- admittedly not very close, though -- is the ability to add a
>> rewriter, which sits in the dispatch path, takes in the #arg, and can
>> produce a modified one if it wants to.
>>
>> Just off the top of my head, it seems like one could do something like
>> servlet filters with an appmod, I think. Register it on /, and give it
>> it's own dispatching configuration and allow plug-ins to register into
>> its request-reply path. It could then receive each request, arrange
>> the ultimate dispatch target (an appmod, a .yaws page, even a file) at
>> the end of plug-in chain, dispatch the #arg into the chain, and then
>> deliver the eventual reply back into Yaws. No doubt this would be
>> easier if it were built into Yaws, though, since reusing the existing
>> dispatch logic would be easier than writing your own.
>>
>
> Yes and presumably to do your webmachine-a-like you'll be using the
> internal dispatch like this anyway, right? But it would definitely be
> better for use the internal dispatch logic. Also is there a straight
> API call back into YAWS for serving a request, especially a file one
> (so that sendfile will kick in if configured) ?

Not really, but I don't think it would be hard to add. Currently, an
out/1 function can return the {page, Page} directive to tell yaws to
re-dispatch the current request to Page, which yaws expects to be an
absolute URI path, but I think that's about it. I know for sure this
works for appmods re-dispatching to files, and looking at the code I
think it works for any general re-dispatch, but I've personally never
tried it for anything other appmods re-dispatching to files.

--steve