App installation and encapsulation (Was: Tandem Expand)

This email has turned into yet another 'os philosophy' discussion,
more than a discussion about VSTa specifics. However, so far it seems
that people here are interested in this sort of thing.

On Wed, Dec 02, 1998 at 09:41:29AM -0500, Gavin Thomas Nicol wrote:
> > I have a qustion. Should we have some sort of VSTa name service? I mean,
> > a lot of the problems involved in using purely symbolic names for things
> > is getting a consistant and expectable result every time.
>
> Well, I was just installing Office 2000 yesterday, and what David
> Jeske said hit me in spades as I watched the install process.

I'm glad you agree.

> We all know the problems caused by windows install programs that
> install things all over the system because they need to live in
> "special" places in order for things to work well (just try
> installing things in non-default places and watch what
> breaks). Worse, uninstall doesn't always clear everything that was
> installed off the machine, so you often get to a point where your
> disk is half full of crud that you don't need, but are not sure that
> you can delete.

Yes, but I think you should ask "why are their special places?". IMO,
the problem is that current single heirarchy filesystems are a blank
untyped slate within which applications create their own add-hoc
storage conventions.

> I think this is a clear example of why we need per-process maps and
> mount overlays... with these, the programs, at starup, would simply
> make the namespace looks like they need it to be, but have the
> actual *installation* of the program be purely local. Uninstall
> would be a snap.

I believe we need to think long and hard about this. How is the
application going to create the per-process maps? If the application
is just accessing absolute names in the namer, and mounting them into
it's pathspace, we have not improved anything.

The idea of putting devices and files into a heirarchy is (IMO) mostly
a convinence to human users. There are much more powerful storage
mechanisms which applications could use just as easily to store data
(i.e. databases, or even flat resource stores with unique
names). However, these storage mechanisms don't translate as well into
something a human user can 'browse'.

A better solution (IMO) is to recognize that the heirarchy (and mount
tables) need to exist for the human interactive mode, and perhaps for
little scripts the operator writes, but that the resources themselves
should exist in a different shape.

For example, we might let an application get an opaque handle to the
'root' of it's files but not connect that to other files via some
add-hoc heirarchy. If a human user wants to muck with the internal
files of an application, let him mount it into his add-hoc pathname
space to browse it.

For example, I assert that it's a better solution for an app to do
something like:

int node_id = open_my_instance_resource(PRIMARY_DATA);
int my_icon = open_resource(node_id,"myicon.tiff");
int my_data = open_resource(node_id,"somedata/my_data.dat");

Than to do something like:

mount_my_instance(PRIMARY_DATA,"/appdata")
int my_icon = open("/appdata/myicon.tiff");
int my_data = open("/appdata/somedata/my_data.dat");

However... either is a much better solution than 99% of operating
systems are doing today, where app resources are installed into add-hoc
locations at install time.

====

I'm going to go into more detail about the suggestion above that I
don't like (i.e. mounting an apps primary data into some fixed
location) both because it's the less radical one, and because it'll
highlight some of the problems to be solved.

We can improve app installation with this mode, but the single
heirachy filesystem gets in the way. For example, we could make an
add-hoc convention for use of the raw FS. This would have applications
installed into instance IDs instead of some developer dictated install
location:

/@apps/0/app_export # a text file describing the app info, name, etc
        /myicon.tiff # app icon
        /somedata/my_data.dat # app data
        /my_app # app binary
/@apps/1/app_export
        /bin-i386/netscape # i386 binary
        /classes.zip # default java classes file
        /icons/netscape.ico # netscape icon
        /icons/html.ico # html file icon
        /icons/tplain.ico # text/plain icon
        /icons/jpeg.ico # jpeg file icon
/users/jeske/@apps/0/... # private app for user jeske

The app_export would contain information like:
# app_export for netscape
APP_ICON = netscape.ico
APP_BINARY{i386} = bin-i386/netscape
APP_FILETYPES = { { type = "text/html", icon = "icons/html.ico",
                       actions = { "open", "edit" } },
                  { type = "text/plain", icon = "icons/tplain.ico",
                       actions = { "open" } },
                  { type = "img/jpeg", icon = "icons/jpeg.ico",
                       actions = { "open" } }
                }
Then when an app (or a command line tool) was launched, we would mount
it's datafiles into a standard location (like /__appdata), and it
could access them all from there.

The problem here is that the "@apps" stuff is just add-hoc convention
stuffed into an untyped heirarchy. (that is, if someone just created a
directory called "@apps", it would be indistinguishable from our apps
directory above) In addition, if we are storing data in the above
manner into the raw-filesystem, then we have to write code to special
case things like the private user app repository, or a group
app-repository. Of course we can use something like union mounts to
push this into a process local pathnamespace, but any decision about
which mounts to make are again, just add-hoc.

The world is a much nicer place if we have a multi-heirarchy, where we
can express the physical storage location as one heirarchy, the
ownership as another, and the identity information as another, and all
of them can be rigidly typed items:

physical location ownership identity class instance

fs/root:home/jeske/my_app users.jeske app/my_app 00
fs/root:home/jeske/netscape users.jeske app/netscape4.05 01
fs/root:apps/gcc users app/gcc2.7.0 02
net/share:apps/gimp users app/gimp 03

That way, when we want to do something like "build the list of
installed applications, we merely list the "identify class" = "app/*".

I think I've gone on long enough about this, thoughts?

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