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

[Edmond Begumisa]

On Tue, 21 Feb 2012 04:13:50 +1100, 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.

I presume that it's more URI-based modularity that you're looking for.  
Note that you can achieve this by using the "yapps" feature by splitting  
your web-application into small OTP applications. Actually, I find that  
this approach promotes more manageable and reusable code.

Using your first example. You could have several OTP applications handling  
auth(entic|oris)ation, accounts, payments, receipts, etc....

== yaws.conf ==
..

runmod = yapp

<server public>
   port = 8000
   listen = 0.0.0.0
   docroot = /PATH_TO_MAIN_DOC_ROOT/www
   arg_rewrite_mod = yapp
   <opaque>
     yapp_server_id = pub
     bootstrap_yapps = accounts, payments, receipts, auth
   </opaque>
</server>

<server admin>
   port = 8001
   listen = 0.0.0.0
   docroot = /PATH_TO_MAIN_DOC_ROOT/www
   arg_rewrite_mod = yapp
   <opaque>
     yapp_server_id = adm_gui
     bootstrap_yapps = yapp
   </opaque>
</server>
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/ebin/accounts.app ==
..
{env, [
          {yapp_appmods,[{"show", accounts_show_controller},
			 "configure", accounts_conf_controller}]}
       ]},
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/src/accounts_show_controller.erl ==
..
out(A) ->
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/src/accounts_conf_controller.erl ==
..
out(A) ->
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/priv/docroot/ ==
Has it's own docroot!


Now whenever http://server:8000/accounts/* is accessed, the accounts OTP  
application will handle it. If it's  
http://server:8000/accounts/configure/*, then the accounts application's  
appmod will handle it.

Then you write other OTP applications for payments, etc, etc. After a  
while, you'll find yourself moving little useful OTP yapp applications  
between projects.

> 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) ?
>

To preempt his response: the hard work has already been done...

http://steve.vinoski.net/blog/2009/01/05/sendfile-for-yaws/

- Edmond -

> BTW thanks for the feedback, this has been very useful and I'm going
> to start playing with YAWS properly now I think.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/