3 arg_rewrite

Yo!

I’ve been working on a way to get various erlyweb apps running simultaneously on the same yaws server.
The first part was getting erlyweb to behave like a good citizen. I did this by converting it to use erlang packages. So far so good.

The worst part so far as been messing around with yaws. :|
I’ve tried the Yapp way of deploying webapps but the deployment is just too complex for me (/other n00bs).

I want to be able to set all apps on a single thing file, like so:
ebin_dir = ebin # here to let yaws know about the rewrite module
ebin_dir = /erlyapps/app1/ebin
ebin_dir = /erlyapps/app2/ebin

### Optional! appX:start() should compile and get the application ready to go
# runmod = app1
# runmod = app2

port = 80
listen = 0.0.0.0
docroot = www
appmods = <“/app1”, erlyweb>
appmods = <“/app2”, erlyweb>

rewriter = “/app1, docroot = /app1/www [, key = value ]*”
rewriter = “/app2, docroot = /app2/www [, key = value ]*”

arg_rewrite_mod = rewriter # this is the module that will make all this possible

Ah! Before I forget! There’s an handy tool for looking at the contents of the #arg record for new requests: yaws_showarg:out(Arg).
The best way to use it is to set it up as an appmod in your yaws configuration file:

appmods = <“/arg”, yaws_showarg>

Let’s get to it!
We need to build the rewriter:arg_rewrite/1 function so that it will:
– match the current request with one of the defined appmods;
– check for a related rewriter config (one of those lines in the opaque section);
– load the config variables and overwrite the request’s Opaque field with those vars (instant app sandboxing :P);
– read the docroot variable from the same config variable as above and use it to change the request’s docroot;
– if the request is for an accessible static file:
– serve the file over a vdir pre-configured as “/docroot/ ” where the first part
will be the #arg.docroot_mount and the second will become the #arg.docroot
– this is more complex than I first thought because we can’t simply return the file
HOLD THAT THOUGHT! I just realized why the yapp module was using the process dictionary!!! :o
Maybe we can do more than what I thought…

Muaahah! :D SUCCESS! :) I have it working. :)
But getting back to my line of though: we can’t simply return the file. The rewriter is just a small piece in serving the request.
We can setup the vdir for serving the file but the request will still be “delivered to the defined appmod” via appmod:out(#arg{}) so we
need to make sure that the last thing the appmod does is to return {page, AppModURI ++ Request} (I had to change erlyweb to do this correctly).
– otherwise, just let the appmod handle the request.

This is an example (supported) configuration:
cache_refresh_secs = 0
logdir = log

ebin_dir = ebin
ebin_dir = C:/yaws/erlyapps/calendar/ebin
ebin_dir = C:/yaws/erlyapps/ems/ebin

runmod = calendar.boot
runmod = ems.boot

port = 80
listen = 0.0.0.0
docroot = www
appmods = <“/arg”, yaws_showarg>
appmods = <“/calendar”, erlyweb>
appmods = <“/ems”, erlyweb>

rewriter = “/calendar, package = calendar, docroot = c:/yaws/erlyapps/calendar/www”
rewriter = “/ems, package = ems, docroot = c:/yaws/erlyapps/ems/www, ems_options = /ems/files/ e:/mp3, vdir = /ems/files/ e:/mp3”

dir_listings = true
arg_rewrite_mod = rewriter

You might have notice that the vdir is present within the “ems” app configuration, this is the same as putting the
definition on a line of its own. Either way the vdir property will get defined as an opaque variable and yaws you create
the mapping.

Remaining thoughts… none for now. This went well! :)