Root appmod

Yaws should serve all static files in docroot, THEN appmods. Here’s why…

As I made my way through all of the DOC and all that Google had to offer…. and then a few postings on Erlyweb. I became apparent to me that root-appmod is a bad thing. In fact, with the exception of ONE edge use-case there is no real use. But first some background:

When it comes to Appmod, yaws provides three options. None, one or many. Skipping the none. The one will only function in the barest of implementations. Where this page is the ONLY page/resource to be retrieved and all external resources are external.

Here is an example of a use-case where there is only one appmod. The universal controller.

yaws.conf:
   ...
   appmod = </,myappmod>

myappmod.erl:

   ...
   out(A) ->
        {yssi,"myhtml.yaws"}.

   say(Word) ->
      Word.

   shout(Word) ->
      {em,[],Word}.

myhtml.yaws:
…

   < h1 >say hello< /h1 >

   < erl >

      out(A) ->  shout("my name").

   < /erl >

   < img src="/images/logo.png" >

the problem with the code above is that the IMG tag is going to load the logo.png file using myappmod. Essentially recursing the flow. Even if you had an instance of apache or lighttpd in front of the yaws deployment to capture the static files it would never be able to catch all of the additional edge cases. Most of my browsers try to load /favicon.ico with every page load. So we’d have yet another rule for gateway.

Keep in mind, using a gateway http server may actually hinder yaws performance. (See the docs on apache vs yaws.) To my knowledge there have been no tests on apache vs apache+yaws; etc…

I do not need to go into examples of the MANY, except to say that since you would not be defining . And everything else should work as expected.

PS: it would be nice if there were some real doc on the yaws.conf:

PPS: it would be nice if there were some real doc on the yaws.conf:mod_rewrite

PPPS: it would be nice if there were a {yssi,“file.yaws”, Bindings}

FWIW: no_appmod + mod_rewrite + binding = root_appmod