[erlang-questions] Stand Alone Erlang or Equivalent

[Benjamin Tolputt]

Kenneth Lundin wrote:
> I think you and many others discussing Standalone Erlang are mixing up
> things here. The important thing for end user deployment is that it is
> easy and quick to install and uninstall a SW package and that does not 
> imply that for example all the beam files must be packed together in 
> one or a few bigger files.
> As long as the installation is distributed as e.g a self extracting
> and self installing exe file  (Windows) it should be ok.
> Of course this package should only contain the beam files from OTP
> that are actually used plus the specific .beam files for the SW in
> question.
>   
I would agree that there seems to be some confusion in the discussion. 
On the other hand, being able to create a single executable (with 
perhaps one or two other files for the related beam archives) is where I 
am coming from.

As I mentioned in an earlier email, the standard in game deployment is a 
single executable, with whatever necessary DLL's required (as few as 
possible), and a small number of (generally large) archive files for the 
game resources (everything from scripts & byte-code to image, models, & 
sound files).

The primary reason I suggested having the beam files "compiled into" the 
executable is that the game publishing industry is quite strict about 
having copyright protection mechanisms embedded into the deployment. I 
am recommending Erlang as the "primary" development language rather than 
just the "scripting" language (as this would make best use of Erlang's 
superior concurrency) and, as such, being able to protect (if only 
marginally) the beam files that actually relate to how Erlang loads 
modules, executes, etc (i.e. the kernel, stdlib, etc) is somoewhat of a 
commercial (as opposed to "technical") necessity.

A single executable with beams in a separate archive (ZIP or otherwise) 
would be suitable with some personal modifications to the Erlang VM's 
source code (i.e. adding in relatively useless encryption).code database 
or zip file)?
> We have already implemented (but not released) code loading from ZIP archives.
>
> We are working on "standalone" features but I can not promise today when we
> will release something.
>   
I understand the need to not make promises, but could we get a "squishy" 
delivery time frame? That is, is this something for "soon" or planned 
for a more "long term" release?
> Erlang/OTP as available today as open source is a DEVELOPMENT SYSTEM
> which the developer uses to create a TARGET SYSTEM. The target system
> can be a simple standalone application to be installed on many clients
> or it can be a complex distributed embedded server system.
>   
Again, something I completely understand. For server deployments 
(requiring hot-swap code updating and the like), the deployment tree as 
it stands works well (and is pretty much a requirement). However, there 
are not many applications I have seen that use Erlang outside this niche.

Given the paradigm shift that has & still is occurring in the game 
development industry toward high concurrency / multi-threaded 
application structures (in order to make full use of multi-core PC's and 
consoles) - I think being able to deploy something that will not 
hot-swap (and hence does not need the large number of "real" files in 
the deployment) will add to Erlang's ability to be used in such an 
environment.
> To create the target system you need the following:
> 1) Know what parts of Erlang/OTP you need in the target app.
> You can pick OTP components on complete application level i.e. stdlib,
> kernel, mnesia etc. which is easy.
> <...snip...>
> 3) Pack 1 and 2 together in a distribution.
> You can pack together all resulting files and directory hierarchies
> just as they are.
> Or you can try to create something which result in just a few files
> when installed (e.g. beam files packed together, one per OTP
> application or one for all .beam files)
> <snip>
> We will primarily address 1 and 3 above and probably offer several
> alternatives for doing them
(1) & (3) are pretty much the essentials for what I am looking at 
anyway. If the code for these deployment tools becomes available, it 
should be fine & dandy to use for deployments where commercial 
considerations require "twiddling" for copyright protection purposes.

Regards,
B.J.Tolputt