Re: App installation and encapsulation (Was: Tandem Expand)

On Thu, Dec 03, 1998 at 12:18:52AM -0500, Gavin Thomas Nicol wrote:
> I've cut out a lot of what you said, mostly because I agree with it. It's
> kind of interesting, because the company I work for is very Unix-like
> in it's resource management for applications. I've been trying for a few
> years now to encapsulate all resources into a single file... but this has
> been an uphill battle.

I don't know how literal you are when you say "encapsulate all
resources into a single file". I definetly agree that there needs to
be some concept of atomicity for the resources for an entity. However,
I think that it can be done just as easily with "more than one file"
as it can be done with "just one file". The important part isn't
necessarily the line we draw in the sand about which code manages the
'multiple resources', but instead the important part is that there is
a way to have an atomic collection of resources.

> That said, I think you have to divide the problem into parts: what the
> application sees, and what the user sees. I very much like the idea
> of packaging an application, and it's resources, into a single file.
> As such, a user should see nothing more than a single file in their
> view of the system.

Agreed. Check out this description of NeXT's app wrapper system for an
example of how this can be done relatively easily within the UNIX
filesystem model. Of course you can make it more robust if you go
further..

http://www.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html

> From an application perspective, it is often necessary to have some
> naming mechanism for handling resources. For example, in a Japanese
> locale, asking for gettext(FOO) (or somesuch call for a resource)
> has to be mapped to *some* way of differentiating Japanese resources
> from Germans ones from French ones. Ultimately, the system will have
> to map to some unique identifier, which is equivalent to a name. At
> that level having the application look for
>
> /app_resources/ja/ui/menu
>
> is as good as a GUID.

I don't think that I agree with you here. The nicest property of using
a flat-namespace like GUIDs is that the GUID dosn't convey any
information except identity. As a result, any orginization you want to
lay on top has to be 'on top', and thus any number of orginizations
can be layed on top without interfering with eachother.

Wheras in your path example above, you've already preconcieved the
importance of the different pieces of information construed in the
heirarchy. Furthermore, because the pieces of information in the
heirarchy are 'add-hoc', there is no way to correctly extend them for
later use.

What happens to the hard coded
sprintf(path,"/app_resources/%s/ui/menu",my_language) when you decide
you also want to have separate resources for different UI 'themes'?
(i.e. win95 vs MacOS). First off, you have to go back and change all
the path construction to have a new field. Secondly, you have to
decide whether you want to do "/app_resources/ja/mac/ui/menu" or
"/app_resources/mac/ja/ui/menu".

I think these kinds of binding issues are better handled if the
binding information is moved outside of the resource request
itself. For example, if your app was merely asking for "ui/menu" or
some GUID identifier, then an external 'binding' can occur to decide
between whatever different supporting contexts there are. In my
expanded example, we have 4:

  lang style

  japan - mac
  japan - windows
  us - mac
  us - windows

but we might just as easily add other languages as we might add yet
another dimension, for different "skill levels" of users:

  lang style skill

  japan - mac - expert
  japan - mac - novice

By encoding this information as a flat set of typed properties which
apply to their associated contexts, we can easily recognize what
possible contexts can be bound and choose between them. If we encode
some pre-ordained heirarchy, we would have instantly limited outselves
from further expansion, and we would have buried information about the
different dimensions in the 'convention' of the heirarchy building.

 (i.e. /app_resources/japan/mac/expert/ui/menu conveys no information
    about what "japan" means, nor does it allow for expansion)

In the model I propose, there are three things which are combined to
figure out how do bind a resource:

1) the identity of the requester
2) the identify of the requested resource
3) the 'binding paramaters' (i.e. in the above case,
                              "lang=japan" and "skill=expert" would be binding
                              paramaters)

> I think the point that you were making is that *this* namespace, and that
> of the filesystem that the user sees, need to be independent of one another.

While it is certainly true that I think these two namespaces shoud be
independent, I still want to move away from encoding useful and
important information in non-typed spaces like a pathname space.

> With a model like this, how are things like system libraries handled
> though?

System libraries are handled in the same spirit as application
resources. That is, binding between an application and a particular
shared lib should not be based on 'what's installed in lib', it should
be based on the three criteria above.

For example, if I'm "cp" (identity of requester) and I'm asking for
"libc-4.0" (identify of requested resource) and there are no special
binding paramaters, then the system will bound to the libc-4.0
compliant lib which is available.

If I'm, "netscape" (identity of requester) and I'm asking for
"libc-4.0" (identity of requested resource) and there is a binding
paramater which says that we're not allowed to use "libc-4.1", then it
won't be bound to libc-4.1, and instead it'll be bound to any other
compliant libc-4.0 provider.

I'm going to warn you now that if this discussion continues, you'll
find that I prefer the 'default' binding behavior to be to only bind
the exact instance of the resource requested (because it's the only
one you _know_ works), and that binding to 'newer and allegedly
compatible versions' would require additional binding
information. However, I thought my example above would be simpler.

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