Longstanding issues: structs & standalone Erlang
Tue Feb 14 14:32:03 CET 2006
On 2006 Feb 14, at 8:15 AM, Daniel Luna indited:
> This is actually a nice idea. I have been toying with it before and
> I had some thought on how to do it (let's see if I can remember any):
> - Some sort of authentication (Erlang cookies are not really enough)
> - Version control of the libraries (which version of "this"
> depends on what version of "that")
This is an old problem, though not solved particularly well in most
cases (COM I think ends up with a proliferation of libraries that you
don't even know why or if you need them. Linux/BSD packaging systems
attempt to solve this too, but I haven't seen any particularly nice
solutions, though I also admit I haven't looked recently. The BSD
Port system seems kind of nice)
> - Preloading of libraries (to make the most use of even a slow
First time start up time is a direct impact on the "out of the box"
experience, and one never gets a second chance at a first impression,
leading directly to:
> - A way to package everything and put it on a computer without net
> (smells like SAE)
I think SAE is a nostalgic death-trap. Most modern applications are
no longer one executable. Mac OS X is leading the way here, making a
folder look like an application is the way to go. This while Windows
is still bunding "resources" into the executable the way Mac OS used
to do. ZIP files and Windows installers (which oft will download the
"real app" from the web) seem to be the norm, and those are typically
more than one file when its all said and done.
> Bad things:
> You will have one copy per user instead of one copy per program.
> This could be worse in a multiuser environment.
> Different programs want to have different versions of libraries.
> Could get really hairy.
Yup, but those two items tend to counter act each other... :-)
> ps. If anyone is starting implementation of any of this, I want in.
More information about the erlang-questions