yaws

Hello Todd,

This is not a compete answer to all your questions. I guess you should 
start with http://yaws.hyber.org/yaws.pdf which offers good reading. I 
do not see Yaws is more complex in its setup than for instance Apache if 
you install it from source.
> 1. When creating a simple web app, where do the various files go? For
> example, it's clear that .yaws and other webby files go under ./www. But
> what about other files, such as .erl? Or appmods, nif and port files?
The .erl files are source files and the appmods and so on are Erlang 
compiled files. The first ones usually are placed in your projects 
source directory. The latter need to be placed in a directory which is 
searched by Erlang. You can add any path to the ebin_dir directive so it 
is flexibility that is your part, comparable with a search path for 
libraries in your OS.
> 3. Root file structure...wow, lots of files here...
Most Linux distributions (at least the Debian and Redhat based ones) 
offer a package. The source from github of course needs to be support 
multiple platforms. Building from source looks therefore always a little 
more complex.
> 4. New app creation is confusing enough, but the docs for embedding yaws
> make my eyes glaze over...seriously, do I need to wade thru all this?
I do not think it can be made much easier but then again I think it is  
beyond usual web application setup. Look for a prebuilt package for your 
distribution if you want a more predefined setup.

Regards,

Tjeerd.

On 14/12/2012 15:21, Todd œ wrote:
> Yaws has lots of great documentation, and then there is the helpful 
> 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still 
> left with some basic questions regarding app creation. Overall, I'm 
> still wondering, where do app files go? And why are there so many files 
> in the yaws root?
> 
> 1. When creating a simple web app, where do the various files go? For 
> example, it's clear that .yaws and other webby files go under ./www. But 
> what about other files, such as .erl? Or appmods, nif and port files?
> 

First of all, there is not only one answer to this question. It is
highly dependent of your application.

One option is to develop your application like a classic Erlang
application[1].
You could also take a look on what is done with the debian packages of yaws:
 * erlang-yaws[2] includes the Erlang Yaws application
 * yaws[3] includes binaries and config to run Yaws in standalone mode
 * yaws-yapp[4] includes the Yapp application

> 2. The documentation for creating a yapp is a bit confusing...
> 
> http://yaws.hyber.org/yapp_intro.yaws
> """
> ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin
> 
> The "applications" part is used for a local_installed Yaws, and "lib" 
> for a real installed one. Then we make sure that the yapp handler 
> application is started when Yaws is started, by using the runmod directive
> """
> 
> Um..., what is the difference between 'applications' and 'lib'?
> 

See http://yaws.hyber.org/configuration.yaws to know the difference
between a local installation and a real installation. You probably need
to use a real installation of Yaws. Local installation is generally used
for development purpose.

> 
> 3. Root file structure...wow, lots of files here...
[...]
> Think about this from the standpoint of someone new (like me) to your 
> webserver. Why am I presented with all these config files, a dir for 
> debian and win32... etc. Couldn't all this be restructured in a cleaner way?
> 

This is the root directory of the project. You should install Yaws
before using it. With a typical installation, you have the following
structure:

 * etc files went into        /etc
 * executables went into      /usr/bin
 * library files went into    /usr/yaws/lib/yaws
 * var files went into        /var
 * default docroot went into  /var/yaws/www


> 4. New app creation is confusing enough, but the docs for embedding yaws 
> make my eyes glaze over...seriously, do I need to wade thru all this?
> 

No, the easiest way to do is to run Yaws in standalone mode. You can
embed Yaws, of course, but in a larger application.


> 5. In general, creating a new app from scratch should be much easier on 
> the developer. Are there plans for creating rebar plugins to:
> 
> * create a new yaws app stack
> * create an embedded yaws app stack
> * add an appmod
> * add a yapp
> 

What do you really mean by "a new app" ?
 * Yapp _IS_ an application. it just need to be installed and
configured. Maybe the documentation should be improved but rebar has
nothing to do here.
 * An appmod is just a single Erlang module which exports the function
out/1 (see http://yaws.hyber.org/appmods.yaws).


> 
> For my current project, I started out looking at yaws but abandoned it 
> for cowboy b/c of all the above friction. Then, I ran into a problem 
> extracting query string params in cowboy. The error msg wasn't useful, 
> there were no docs for that feature, and I didn't want to debug it 
> and/or bother the owner. So I came back to yaws b/c it had 
> documentation. I really enjoy using it, but I'm left with the overall 
> feeling that I'm not 'doing it right'.
> 

What do you want to do ? It would be easier to help you with details on
your application.


[1] http://www.erlang.org/doc/design_principles/applications.html#app_dir
[2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist
[3] http://packages.debian.org/sid/all/yaws/filelist
[4] http://packages.debian.org/sid/all/yaws-yapp/filelist

-- 
Christopher

Christopher, Tjeerd -

Thank you for your responses. I think the disconnect here is that I'm 
approaching this with the goal of building stand-alone applications, 
where the front end (user interface) is decoupled from the back end:

Application
------------
* user interface
	web|qt|whatever -> talking REST to backend
* backend
	REST backend (could be python|java|erlang|whatever)


I've written a test bed application suite consisting of the following 
application stacks:

Test Apps
---------
1. Common WebApp
	angularjs web app talking REST and websockets to backend
2. Desktop/Server
	REST/Websockets implemented on jetty and erlang (cowboy|yaws)
3. Android Mobile
	REST/Websockets implemented on i-jetty (standard java servlets)

So basically, I deploy a common webapp to a variety of containers as a 
way of both learning the various technologies, and also as a way of 
developing a template for developing cross platform applications.

I can see how yaws was probably developed to be installed on a server 
once, and then applications would be installed into it via adding an 
ebin_dir entry in yaws.conf. Thats certainly clean and simple.

Correct me if I'm wrong, but it does seem a bit different from the 
rebar/erlang way of doing things. When creating apps with rebar and 
reltools, the approach seems to be: declare your deps, and package up 
everything into a fat release, including your erlang distribution. It 
took me awhile to get comfortable with that approach, too... I kept 
thinking, "what? I'm including the entire erlang runtime with every 
application?" Seemed crazy when I first saw it. But I can see the 
advantages now.

Anyway, even though I'm writing a smallish application, perhaps 
embedding yaws is the appropriate strategy...

Thanks again,
-Todd

p.s.

As a side note...

With respect to a permanently installed service, such as a java servlet 
container...I'm used to deploying a war to the server, blah blah. The 
app definition/interface is simple, and deploying the bits to the 
servers is all very similar. So, when yaws is installed as a service... 
what's the common way of packaging up a 'yaws web application' and 
deploying it to a 'yaws server'? In practice, do you really just copy 
your app to a dir on your production server and manually (or via 
puppet/chef/whatever) update your yaws.conf ebin_dir entries?

-t

On 12/14/2012 05:54 PM, Christopher Faulet wrote:
> On 14/12/2012 15:21, Todd œ wrote:
>> Yaws has lots of great documentation, and then there is the helpful
>> 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still
>> left with some basic questions regarding app creation. Overall, I'm
>> still wondering, where do app files go? And why are there so many files
>> in the yaws root?
>>
>> 1. When creating a simple web app, where do the various files go? For
>> example, it's clear that .yaws and other webby files go under ./www. But
>> what about other files, such as .erl? Or appmods, nif and port files?
>>
>
> First of all, there is not only one answer to this question. It is
> highly dependent of your application.
>
> One option is to develop your application like a classic Erlang
> application[1].
> You could also take a look on what is done with the debian packages of yaws:
>   * erlang-yaws[2] includes the Erlang Yaws application
>   * yaws[3] includes binaries and config to run Yaws in standalone mode
>   * yaws-yapp[4] includes the Yapp application
>
>> 2. The documentation for creating a yapp is a bit confusing...
>>
>> http://yaws.hyber.org/yapp_intro.yaws
>> """
>> ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin
>>
>> The "applications" part is used for a local_installed Yaws, and "lib"
>> for a real installed one. Then we make sure that the yapp handler
>> application is started when Yaws is started, by using the runmod directive
>> """
>>
>> Um..., what is the difference between 'applications' and 'lib'?
>>
>
> See http://yaws.hyber.org/configuration.yaws to know the difference
> between a local installation and a real installation. You probably need
> to use a real installation of Yaws. Local installation is generally used
> for development purpose.
>
>>
>> 3. Root file structure...wow, lots of files here...
> [...]
>> Think about this from the standpoint of someone new (like me) to your
>> webserver. Why am I presented with all these config files, a dir for
>> debian and win32... etc. Couldn't all this be restructured in a cleaner way?
>>
>
> This is the root directory of the project. You should install Yaws
> before using it. With a typical installation, you have the following
> structure:
>
>   * etc files went into        /etc
>   * executables went into      /usr/bin
>   * library files went into    /usr/yaws/lib/yaws
>   * var files went into        /var
>   * default docroot went into  /var/yaws/www
>
>
>> 4. New app creation is confusing enough, but the docs for embedding yaws
>> make my eyes glaze over...seriously, do I need to wade thru all this?
>>
>
> No, the easiest way to do is to run Yaws in standalone mode. You can
> embed Yaws, of course, but in a larger application.
>
>
>> 5. In general, creating a new app from scratch should be much easier on
>> the developer. Are there plans for creating rebar plugins to:
>>
>> * create a new yaws app stack
>> * create an embedded yaws app stack
>> * add an appmod
>> * add a yapp
>>
>
> What do you really mean by "a new app" ?
>   * Yapp _IS_ an application. it just need to be installed and
> configured. Maybe the documentation should be improved but rebar has
> nothing to do here.
>   * An appmod is just a single Erlang module which exports the function
> out/1 (see http://yaws.hyber.org/appmods.yaws).
>
>
>>
>> For my current project, I started out looking at yaws but abandoned it
>> for cowboy b/c of all the above friction. Then, I ran into a problem
>> extracting query string params in cowboy. The error msg wasn't useful,
>> there were no docs for that feature, and I didn't want to debug it
>> and/or bother the owner. So I came back to yaws b/c it had
>> documentation. I really enjoy using it, but I'm left with the overall
>> feeling that I'm not 'doing it right'.
>>
>
> What do you want to do ? It would be easier to help you with details on
> your application.
>
>
> [1] http://www.erlang.org/doc/design_principles/applications.html#app_dir
> [2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist
> [3] http://packages.debian.org/sid/all/yaws/filelist
> [4] http://packages.debian.org/sid/all/yaws-yapp/filelist
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
>
> _______________________________________________
> Erlyaws-list mailing list
> Erlyaws-list@...
> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>


-- 
Todd Greenwood-Geer

Ok, getting yaws running as an embedded app wasn't so hard, after all...

Now, the directory structure that I deal with is nice and clean:

[todd@... rebar-yaws (master)]$ tree -L 2
.
├── deps
│   ├── mimetypes
│   ├── mochiweb
│   └── yaws
├── ebin
│   ├── launch.beam
│   ├── myapp.app
│   ├── myapp_app.beam
│   └── myapp_sup.beam
├── Makefile
├── rebar.config
├── src
│   ├── launch.erl
│   ├── myapp_app.erl
│   ├── myapp.app.src
│   └── myapp_sup.erl
└── webapp
     └── webappname


I use a trimmed down Makefile from cowboy, that's probably got a long 
lineage...

	https://gist.github.com/4296427

My rebar.config is pretty basic...

	https://gist.github.com/4296472

And, as the line in the makefile shows ('erl -pa ebin deps/*/ebin -s 
launch ...'), I just have a simple launch.erl to start things up...

	https://gist.github.com/4296452


Thanks again. I'm looking forward to exploring yaws more.

-Todd

links
http://yaws.hyber.org/embed.yaws
http://stackoverflow.com/questions/11876263/yaws-as-rebar-dependency

On 12/15/2012 09:14 AM, Todd Greenwood-Geer wrote:
> Christopher, Tjeerd -
>
> Thank you for your responses. I think the disconnect here is that I'm
> approaching this with the goal of building stand-alone applications,
> where the front end (user interface) is decoupled from the back end:
>
> Application
> ------------
> * user interface
>      web|qt|whatever -> talking REST to backend
> * backend
>      REST backend (could be python|java|erlang|whatever)
>
>
> I've written a test bed application suite consisting of the following
> application stacks:
>
> Test Apps
> ---------
> 1. Common WebApp
>      angularjs web app talking REST and websockets to backend
> 2. Desktop/Server
>      REST/Websockets implemented on jetty and erlang (cowboy|yaws)
> 3. Android Mobile
>      REST/Websockets implemented on i-jetty (standard java servlets)
>
> So basically, I deploy a common webapp to a variety of containers as a
> way of both learning the various technologies, and also as a way of
> developing a template for developing cross platform applications.
>
> I can see how yaws was probably developed to be installed on a server
> once, and then applications would be installed into it via adding an
> ebin_dir entry in yaws.conf. Thats certainly clean and simple.
>
> Correct me if I'm wrong, but it does seem a bit different from the
> rebar/erlang way of doing things. When creating apps with rebar and
> reltools, the approach seems to be: declare your deps, and package up
> everything into a fat release, including your erlang distribution. It
> took me awhile to get comfortable with that approach, too... I kept
> thinking, "what? I'm including the entire erlang runtime with every
> application?" Seemed crazy when I first saw it. But I can see the
> advantages now.
>
> Anyway, even though I'm writing a smallish application, perhaps
> embedding yaws is the appropriate strategy...
>
> Thanks again,
> -Todd
>
> p.s.
>
> As a side note...
>
> With respect to a permanently installed service, such as a java servlet
> container...I'm used to deploying a war to the server, blah blah. The
> app definition/interface is simple, and deploying the bits to the
> servers is all very similar. So, when yaws is installed as a service...
> what's the common way of packaging up a 'yaws web application' and
> deploying it to a 'yaws server'? In practice, do you really just copy
> your app to a dir on your production server and manually (or via
> puppet/chef/whatever) update your yaws.conf ebin_dir entries?
>
> -t
>
> On 12/14/2012 05:54 PM, Christopher Faulet wrote:
>> On 14/12/2012 15:21, Todd œ wrote:
>>> Yaws has lots of great documentation, and then there is the helpful
>>> 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still
>>> left with some basic questions regarding app creation. Overall, I'm
>>> still wondering, where do app files go? And why are there so many files
>>> in the yaws root?
>>>
>>> 1. When creating a simple web app, where do the various files go? For
>>> example, it's clear that .yaws and other webby files go under ./www. But
>>> what about other files, such as .erl? Or appmods, nif and port files?
>>>
>>
>> First of all, there is not only one answer to this question. It is
>> highly dependent of your application.
>>
>> One option is to develop your application like a classic Erlang
>> application[1].
>> You could also take a look on what is done with the debian packages of
>> yaws:
>>   * erlang-yaws[2] includes the Erlang Yaws application
>>   * yaws[3] includes binaries and config to run Yaws in standalone mode
>>   * yaws-yapp[4] includes the Yapp application
>>
>>> 2. The documentation for creating a yapp is a bit confusing...
>>>
>>> http://yaws.hyber.org/yapp_intro.yaws
>>> """
>>> ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin
>>>
>>> The "applications" part is used for a local_installed Yaws, and "lib"
>>> for a real installed one. Then we make sure that the yapp handler
>>> application is started when Yaws is started, by using the runmod
>>> directive
>>> """
>>>
>>> Um..., what is the difference between 'applications' and 'lib'?
>>>
>>
>> See http://yaws.hyber.org/configuration.yaws to know the difference
>> between a local installation and a real installation. You probably need
>> to use a real installation of Yaws. Local installation is generally used
>> for development purpose.
>>
>>>
>>> 3. Root file structure...wow, lots of files here...
>> [...]
>>> Think about this from the standpoint of someone new (like me) to your
>>> webserver. Why am I presented with all these config files, a dir for
>>> debian and win32... etc. Couldn't all this be restructured in a
>>> cleaner way?
>>>
>>
>> This is the root directory of the project. You should install Yaws
>> before using it. With a typical installation, you have the following
>> structure:
>>
>>   * etc files went into        /etc
>>   * executables went into      /usr/bin
>>   * library files went into    /usr/yaws/lib/yaws
>>   * var files went into        /var
>>   * default docroot went into  /var/yaws/www
>>
>>
>>> 4. New app creation is confusing enough, but the docs for embedding yaws
>>> make my eyes glaze over...seriously, do I need to wade thru all this?
>>>
>>
>> No, the easiest way to do is to run Yaws in standalone mode. You can
>> embed Yaws, of course, but in a larger application.
>>
>>
>>> 5. In general, creating a new app from scratch should be much easier on
>>> the developer. Are there plans for creating rebar plugins to:
>>>
>>> * create a new yaws app stack
>>> * create an embedded yaws app stack
>>> * add an appmod
>>> * add a yapp
>>>
>>
>> What do you really mean by "a new app" ?
>>   * Yapp _IS_ an application. it just need to be installed and
>> configured. Maybe the documentation should be improved but rebar has
>> nothing to do here.
>>   * An appmod is just a single Erlang module which exports the function
>> out/1 (see http://yaws.hyber.org/appmods.yaws).
>>
>>
>>>
>>> For my current project, I started out looking at yaws but abandoned it
>>> for cowboy b/c of all the above friction. Then, I ran into a problem
>>> extracting query string params in cowboy. The error msg wasn't useful,
>>> there were no docs for that feature, and I didn't want to debug it
>>> and/or bother the owner. So I came back to yaws b/c it had
>>> documentation. I really enjoy using it, but I'm left with the overall
>>> feeling that I'm not 'doing it right'.
>>>
>>
>> What do you want to do ? It would be easier to help you with details on
>> your application.
>>
>>
>> [1] http://www.erlang.org/doc/design_principles/applications.html#app_dir
>> [2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist
>> [3] http://packages.debian.org/sid/all/yaws/filelist
>> [4] http://packages.debian.org/sid/all/yaws-yapp/filelist
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>>
>>
>>
>> _______________________________________________
>> Erlyaws-list mailing list
>> Erlyaws-list@...
>> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>>
>
>


-- 
Todd Greenwood-Geer

Others have already chimed in and helped, but I just wanted to add the
comments below:

On Fri, Dec 14, 2012 at 9:21 AM, Todd Greenwood
<t.greenwoodgeer@...:

> For my current project, I started out looking at yaws but abandoned it

for cowboy b/c of all the above friction. Then, I ran into a problem
> extracting query string params in cowboy. The error msg wasn't useful,
> there were no docs for that feature, and I didn't want to debug it
> and/or bother the owner. So I came back to yaws b/c it had
> documentation. I really enjoy using it, but I'm left with the overall
> feeling that I'm not 'doing it right'.
>

I'd recommend asking specific questions about your app in cases like this.
Generally I think you'll find that you get helpful answers pretty quickly
on this list.

Also keep in mind that yaws is nearly a decade older than rebar, and so the
way yaws has been successfully deployed for years naturally differs from
the rebar approach. Adding to that is the fact that there are non-trivial
differences between an Apache-like server deployment model and an embedded
deployment model, yet unlike other Erlang web servers yaws supports both
pretty well. Yaws has rebar support, of course, but if you find issues or
problems with it, please just report them here or as github issues on the
yaws repo and we'll address them pretty quickly. And finally, if you have
ideas or suggestions that would make the combination of rebar and embedded
yaws easier from the development or deployment perspectives, let us know
about that too.

thanks,
--steve