[erlang-questions] ErlyWeb

[Mikael Karlsson]

I agree with all your statements, maybe I was a bit unclear in my own ones,
I did not mean that you should mix infrastructure applications and web 
applications (actually one of the reasons I started to work on yapp), but 
that it is good to try and fit web applications, developed with ErlyWeb for 
instance, into an OTP style.
One of the reasons for doing so is that you can make use of the OTP release 
handler for adding/upgrading your web apps while the server(s) is (are) 
running.
The problem is that, as you say, have different roles: Server maintainer, app 
deployer, web applications developer, and as an applications developer you do 
not have control over all the other applications running on the web server 
that makes up to one OTP release package. 

This means that one actually have to build OTP release package scripts on the 
web server in order to deploy new (or upgrade old) web applications (or 
infrastucture apps from Erlang/OTP itself or Yaws.) I do not think this is a 
problem if you have the right tools made.

I look forward to see the presentations on ErlHive at EUC and see what it 
brings to us, but Ulf has also made a nice OTP Release handling tutorial on 
trapexit.org which I can recommend, and one of the things that you learn is 
that you can have several "roots" for different application types.
The directory structure I would like to see for an Enterprise Yaws/ErlyWeb 
would be something like:

/usr/local/lib/erlang - for Erlang/OTP

/home/yaws/yawsroot/  - Yaws/web infrastructure apps
   lib/yaws-1.65/
   lib/yaws-1.62/
   lib/yapp-0.2/
   lib/yfront-1.0/
   lib/ydeployrelease-1.0/
   lib/erltl-xx/
   lib/younameit-x.y/

/home/yaws/approot/   Web apps root
  releases/   - OTP Release handler stuff
  lib/webapp1-1.2/
  lib/webapp1-1.3/
  lib/webapp2-1.0/
  uzw.

So I develop my web app, tar it, HTTP POST it to my web server(s) app download 
directory, and let the deployer, which probably is also me, untar it in the 
webapps lib directory, make new OTP release package files, and deploy it 
( all this using a nice web GUI developed in ErlyWeb, and having support for 
clustered servers, of course :-). 

/Mikael

On Mov 01 2006 06:16 Jon Hancock wrote:
> On Oct 31, 2006, at 3:02 PM, Mikael Karlsson wrote:
>...
> > Observation:
> > Erlang/OTP by default packages the app/ebin and app/priv
> > directories into
> > releases (functions like systools:make_tar/2 etc). So you might
> > consider
> > using priv/www (or priv/docroot) instead of www as your docroot
> > directory.
> > Not a big deal really since you can include other directories too with
> > optional parameters to systools:make_tar, but it could be good to
> > stick to
> > the OTP default way.
> > Yaws itself does not do this, but uses the www directory for some
> > reason.
> > Maybe the Yaws www files are not supposed to be in ones own web
> > application
> > release.
>
> I think its best to keep apps developed on yaws/erlyweb separate from
> the yaws/erlyweb libraries.
> This means doing things pretty much inline with how Yariv has
> released things.  There are a few minor structural problems with the
> current app directories.  And there is a need to move the erlyweb
> libraries themselves into an OTP style and encourage its installation
> in the erlang libs directory.  But I would not suggest to merge the
> two worlds.
>
> As a point to consider, think of the type of user that updates the
> core erlang/OTP libraries on a server compared to the app programmer
> working with the www structure.  These are two very different roles
> (even if its the same person).
>
> As to the yaws install structure.  I'm not a huge fan of its
> defaults, but they are easily changed and the defaults are sane.  I
> put yaws log/temp/conf and the apps that run on yaws in their own
> yaws home owned by a yaws user/group.  I leave the yaws libraries
> installed in their default install location.
>
> I'm guessing that projects like yapp and some stuff Ulf has alluded
> to will round up the overall structure and things will come together
> in a few more months.
>
> ke han