Yaws Deployment

After these exercises I can now describe the various webapp deployment options possible using yaws.

A – One Yaws server (might have various Servers configured)

A1 – One yaws server serving static/dynamic yaws files
This is the most similar thing we have with serving PHP files via Apache.
In this scenario all yaws files are independent (which is nice).
Question: how hard would it be to enable “folder hierarchy code lookup”?
Before looking up code in the yaws ebin folders we could look it up in the “folder hierarchy” thus enabling webapp sandboxing (which would be nice).
The yaws pages can acess code defined in other modules, if these are in the server’s “ebin_dir path”.

A2 – One yaws server with appmods
Urls configured in the appmods are not served by yaws but by the related modules.
These modules have full control over the request and can implement whatever logic they seem fit.
ErlyWeb is an example of an application which is configured as an appmod and which implements a MVC framework over the “Url space” it manages.
The modules defined as appmods must be defined in the “ebin_dir path” → which is a bit of a downside as this means that there will be code clashes
if different appmods contain modules with the same names (this happens with erlyweb!).

A3 – One yaws server using yapps
This deployment differs from the previous one in that instead off mapping Urls to “simple” apps, Urls are mapped to OTP applications
(under which appmod configuration is still possible).
This method stores the Url <→ App mapping on a mnesia table (other storages available) and requires that the yapp modules takes over url rewritting. Nothing special…
The problem with code clashing remains.

A4 – Using Yawn! :) This is a mix between the A2 and A3 (but easier to use ;)).
The same module can be configured as an appmod configured in different URI/paths with the docroot (and opaque varaibles)
being defined on a per appmod path basis.
The problem with code clashes remains.

A5 – Other solutions that mix erlyweb and yapps simply set up erlyweb as an appmod within an outer OTP application.
This is actually quite interesting in that a normal erlyweb application has no way of starting long running processes.
Humm… well, that’s not that serious after all. We can always start a OTP Application (that starts those long running processes) via yaws runmod.
It’s just a matter of setting up a small deployment script.

B – Several Yaws servers

B1 – Embedded yaws (http://blog.socklabs.com/2008/02/embedded_applications_with_yaw/)
A yaws server can be executed from within another app if running in embedded mode (with the server configurations being feed directly,
without resorting to static files). In this scenario, code clashing can be prevented if each server uses it’s own ebin folders.
The only restriction is that no two servers try to use the same IP/port combination.

B2 – Various standalone yaws servers
If run using different ebin folders, the various servers can function independently without any code clashing.

UPDATE:
Regarding code clashes I’m glad to informat that erlang as support for packages (à la Java):
http://www.erlang.org/doc/man/packages.html
:)