Yaws is ideal to embed inside another larger erlang application. Many typical erlang applications are control applications in need of a webgui specific for the actual application.
In order to run Yaws inside another application, we need to perform the following steps.
Either integrate yaws into the build system of the larger application or specifically provide the ebin path to yaws for the larger application.
Provide the application environment {embedded, true} to Yaws.
The large application typically has it's configuration data fed from internal databases, anyway it's usually not feasible to let Yaws read it's configuration data from /etc/yaws.conf.
To solve this, when Yaws is started in embedded mode, it doesn't read it's config from /etc/yaws.conf, rather it expects the larger application to feed it the Yaws configuration through the function call yaws_api:setconf(GC, Groups)
The two arguments here are
GC is a #gconf{} record. The definition of the record is:
%% global conf
-record(gconf,{file,
yaws_dir,
tty_trace = false,
trace,
debug,
logdir,
ebin_dir = [],
runmods = [],
keepalive_timeout = 15000,
max_num_cached_files = 400,
max_num_cached_bytes = 1000000, %% 1 MEG
max_size_cached_file = 8000,
large_file_chunk_size = 10240,
cache_refresh_secs = 30, % seconds (auto zero when debug)
default_type = "text/html",
timeout = 30000,
include_dir = [],
mnesia_dir = [],
yaws, %% server string
username, %% maybe run as a different user than root
uid %% unix uid of user that started yaws
}).
The easiest way to figure out what the individual record fields mean is to have a look in the source file yaws_config.erl
Groups, is a list of lists of #sconf records. Yaws is capable of listening on several IP address and also do Virtual Hosting on each IP address.
Each #sconf{} record describes one web server, whereas a list of #sconf{} records describe a web server Virt Hosting several different servers.
The sconf record is defined as:
-record(ssl,
{
keyfile,
certfile,
verify = 0,
depth = 1,
password,
cacertfile,
ciphers,
cachetimeout}).
%% a list of lists of #sconfs
%% one list of #sconf's per listen ip
%% server conf
-record(sconf,
{port = 8000, %% which port is this server listening to
rhost, %% forced redirect host (+ optional port)
rmethod, %% forced redirect method
docroot, %% path to the docs
access_log = true, %% log acces
listen = {127,0,0,1}, %% bind to this IP, {0,0,0,0} is possible
servername = "localhost", %% servername is what Host: header is
add_port = true, %% add port after reading config
ets, %% local store for this server
ssl,
authdirs = [],
partial_post_size = nolimit,
appmods = [], %% list of modules for this app
errormod_404 = yaws_404, %% the default 404 error module
errormod_crash = yaws_404, %% use the same module for crashes
arg_rewrite_mod = yaws,
tilde_expand = false, %% allow public_html user dirs
dir_listings = false, %% allow dir listings
opaque = [], %% useful in embedded mode
start_mod, %% user provided module to be started
allowed_scripts = [yaws]
}).
The following three functions yaws:start_embedded/1,2,3 will start Yaws in embedded mode and provide the minimal information that Yaws requires.
NB: With this method you don't need to specify any -yaws switches to your (system) start script.
The only thing that you really need to specify is the "DocRoot", i.e the directory path to where your .html and .yaws files lives. You will then get the same default values for all the other configuration parameters as you can find in the yaws.hrl header file. So, for example: your server name will be: localhost, listen port: 8000, etc.
By using yaws:start_embedded/2 you can set some other values than the default ones for the server configuration (#sconf{}), and with yaws:start_embedded/3 you also can specify global configuration (#gconf{}. See the example below:
%%
%% Check with inet:i(). that you are listening to port 8000!
%%
1> yaws:start_embedded("/home/tobbe/docroot").
%%
%% Alternative ways
%%
1> yaws:start_embedded("/home/tobbe/docroot", [{servername, "sej"}, {listen, {0,0,0,0}}]).
1> yaws:start_embedded("/home/tobbe/docroot",
[{servername, "sej"}, {listen, {0,0,0,0}}],
[{auth_log, false}, {copy_errlog, false}]).
If you need more control on how to setup Yaws in embedded mode, then read on.
We provide a minimal example which "embeds" yaws in a normal Erlang shell.
We start Erlang as:
# erl -pa /usr/local/lib/yaws/ebin -yaws embedded true -s ybed
The ybed module is very small and is named ybed.erl
The above "erl" command line gives:
# erl -pa /usr/local/lib/yaws/ebin -yaws embedded true -s ybed Erlang (BEAM) emulator version 5.3.b1 [source] [hipe] Eshell V5.3.b1 (abort with ^G) 1> =INFO REPORT==== 25-Nov-2003::00:27:18 === Yaws: Listening to 0.0.0.0:8888 for servers - foobar under /tmp 1>
The actual web server then runs inside the larger application and _all_ that remain is to design a decent web GUI. This is harder than it might seem at a first glance. The configuration of the web server was programmatically fed into Yaws from the surrounding application, in this case, the Erlang shell + the module ybed.erl
The sconf structure (which is constructed by the program that starts and configures Yaws), contains a field, SC#sconf.opaque
This field is passed on into the #arg{} record, so that any application specific configuration data which is needed by the .yaws pages that make up the web GUI application, is easily available there.
In essence, if we construct the #sconf as
SC#sconf{opaque = {mystruct, foobar},
.....
A .yaws web page, can do:
out(Arg) -> MyStruct = Arg#arg.opaque .....
Thus passing data from the surrounding applications configuration routines down to each .yaws web page.
Another important fact to consider when choosing weather to run your yaws application as an embedded yaws app or not is that all the yaws control functions are disabled when we use yaws as an embedded web server. I.e yaws --ls, yaws --stop etc. This under the assumption that you already have support for this type of functionality in your application.
