Re: UNIX system or .app?

[David Jeske <jeske home chat net>]

On Sat, Oct 03, 1998 at 05:33:47PM -0400, Daniel_Burrows@brown.edu wrote:
> So please keep the temperature of the flames down?

Will do, no flames here... :)

>   My feeling here is that both sides of the argument have some merit. 
> I really, _really_ like the UNIX system of dividing data up by type into
> /etc, /bin, /sbin, and so on.  At least, I like it from the point of
> view of installing system-wide programs, since all my programs go in
> /bin, all my config files go in /etc or occasionally a subdirectory of
> that, and so on.  Data organization by type rather than package.  

Actually... You are mis-understanding the 'app-wrapper' data-orginization.

The app-wrapper concept divides data along different lines. Instead of
the /etc, /bin, etc.. concept of UNIX where you divide data from
config from binary files, the app-wrapper concept only makes one
division "non-mutable" data (i.e. data required to launch the app in
it's virgin state) goes inside the wrapper, and "mutable" data
(i.e. user or site specific configuration information, etc), goes
outside the wrapper.

So in the app-wrapper orginization, an app can choose to load it's
'default/virgin' configuration information from a file within the
wrapper, but any changes which a user or admin makes which are
specific to this site's configuration should be stored outside the
wrapper, hopefully in some preference system like libPropList.

This assures that you can always separate the 'site specific' from the
'user specific' from the 'app specific' components. In other words, I
can install a program, you can configure it for your system, and I can
still copy the 'virgin' wrapper to another machine and make it work
like it was freshly installed.

> As some people have pointed out, this can decrease location
> independence. 

Actually, the idea of location independence is only 'quasi' related to
this. We can do location independence whether the app is stored in a
wrapper or not. For example, in the legacy unix system, all apps could
be setup to find their datafiles by (a) finding the binary location,
and then (b) going up a directory, and then back down 'relative' from
there to find the datafile. This would work in the non-wrappered case also.

Of course you can have collisions in the non-wrappered case where two
apps have datafiles or config files with the same name, while in the
wrappered case, this dosn't happen, because each wrapper's files are
stored separately.

>   What I'm wondering is--why are the two methods mutually exclusive?  I
> may be missing some blatantly obvious technical argument here, in which
> case I'm sure I'll be flamed to ashes for it, but it doesn't seem to me
> like there's any reason (aside from a small amount of trouble for the
> developer) that an app can't use BOTH methods of getting data/config
> files, either system-wide (/etc, /lib, /share,...) or from a directory.

They are not. However, you must have location independence to do the
wrapper thing correctly, but you don't have to have location
independence to do the UNIX thing.

> Is there any reason that the proposed library can't allow an
> application to be compiled either way? (perhaps a compiletime option
> overridable by a runtime switch?)  I think if it did, I'd see it as a
> Good Thing, but all the comments I've heard from the .app people have
> been focusing on converting the world over to .app (at least, that's
> how I read it, correct me if I'm wrong. :-) )  

It would even be possible (with some ugliness for the compromise) to
have a _binary_ support both modes of finding datafiles.

The issue which causes problems is that in an app-wrapper scenerio you
can NEVER modify the files within the wrapper... that's the whole
point. If you want to configure something, you store that
configuration outside the wrapper in a preference system of some
kind. This guarantees that a user can copy the app somewhere else and
launch it, and it'll work as it should. Or that the user can blow away
the configuration data for an app, and it'll run just like it was just
installed. Or that a user can login to a different platform
(i.e. different processor) and his configuration data still works with
the app compiled for the new platform.

For system tools like "httpd" or whatever, this dosn't necessarily
make as much sense. However, most end-user programs already come close
to this, they just are not exactly this. For example netscape shoves
all it's datafiles into the executable itself, and stores it's user
specific configuration in a dot file in the user's home
directory. It's just not always practical to shove all an app's
datafiles into the executable. (imagine if all of emacs' elisp was
shoved into the exe).

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net