Something I just thought about. I am uncomfortable with having to know internal details about Yaws in order to use it in embedded mode. For example, knowing the yaws_sup is the top-level supervisor is an internal detail. If the architecture changes later, it will break my application. That's why I was trying to use only yaws:start_embedded. I also don't like having to use the #gconf and #sconf records directly, and having to set  a different application's environment variable. In fact, there's a big, fat warning in the documentation precisely about this:


Use this function only if you know what you are doing, that is, on your own applications. It is very application and configuration parameter dependent when and how often the value is read by the application, and careless use of this function may put the application in a weird, inconsistent, and malfunctioning state."

The yaws:start_embedded function tries to hide the internal details by accepting property lists instead of sconf and gconf records, which I think is the right way to do things.

While I work on this, seeing as I have to read the source code anyway, I'll see if I can work out a less intrusive way to start Yaws in embedded mode as part of a supervisor tree, even if it means modifying Yaws source code.

Thanks again for your help.

On Mon, Aug 4, 2008 at 4:59 AM, Oscar Hellström <> wrote:
Hi Edwin,

If you take a look at how OTP handles Included Applications [1] you can see how an "embedded" application is supposed to be started.

Al least in Yaws 1.68, the top supervisor is called yaws_sup and can be started with the following child definition in your supervisor:
Yaws = {yaws, {yaws_sup, start_link, []},
               permanent, infinity, supervisor, [yaws_sup]}
Before doing this though you should set the environment variable embedded to true for yaws: application:set_env(yaws, embedded, true).
After it's started, you'll need to feed some configuration, which can be done with the yaws_api:setconf/2.

Your application callback (for the application including/embedding yaws) can look like:
application:set_env(yaws, embedded, true),
{ok, Pid} = my_top_sup:start_link(), % This has to have the yaws child
                                    % definition somewhere
Docroot = code:priv_dir(wv_client),
GConf = #gconf{
       trace = false,
       logdir = filename:join([code:root_dir(), "log"]),
       tmpdir = "/tmp/",
       yaws = "ICQ/AIM WAPSMS CIR",
       flags =
               ?GC_COPY_ERRLOG bor
               ?GC_FAIL_ON_BIND_ERR bor
SConf = #sconf{
       port = Port,
       docroot = Docroot,
       appmods = [{"/path", my_callback_module}],
       listen = {0,0,0,0},
       servername = "icq_aim"          },
yaws_api:setconf(GConf, [[SConf]]),
{ok, Pid}.

[1] -

Edwin Fine wrote:
I am using Yaws 1.77 in embedded mode in an application. Starting Yaws in
embedded mode starts Yaws as a separate application. The supervisor
(yaws_sup) restart strategy changed since Yaws 1.76 (?) to not restart, for
understandable reasons given in the source code.

Here's the thing: if for example the gserv process dies, then yaws_server
crashes and the entire yaws application dies. I can't figure out how to
detect that it died so that I can restart it from within my supervisor,
because yaws:start_embedded() returns only the atom ok (no pid to link to).
What do I link to in order to detect the crash, or what other mechanism
should I use? I just can't figure it out.



This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world


Erlyaws-list mailing list

Best regards
Oscar Hellström,
Office: +44 20 7655 0337
Mobile: +44 798 45 44 773
Erlang Training and Consulting

For every expert there is an equal and opposite expert - Arthur C. Clarke