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

On Fri, Dec 04, 1998 at 07:08:15PM -0500, Gavin Thomas Nicol wrote:
> I was not arguing for a standard heirarchy, I was just saying that the
> namespace is entirely internal to the app. So
>
> /app_resources/ja/ui/menu
>
> could be just as useful as
>
> menu ja 0001 HAFFF556880-0000
>
>
> for example. From a resource discovery and management perspective, I think
> most programmers will find heirarchies much more natural. Again, this is
> really local to the application *unless* you want some way of exposing this
> to the outside world.
>
> If you want to, in a common way, expose the inner structure to the outside
> world, you *must* have some convention, be it by naming, or by providing
> programmatic hooks.

I don't mean to sound like a broken record, but I think any time you
expose information by 'convention' you are asking for trouble. I would
prefer if _in all cases_ the way you export and import information was
statically verifyable for static dependencies. This means that if your
program requires a particular datafile, that this datafile dependence
be published as an import and statically verifyable. If you encode the
location of this datafile inside a convention within a string within
the app, then there is no declaration to the outside world of this
dependence.

So, I'm not saying that using a heirarchy is necessarily a bad idea,
what I'm saying is that burying the above heirarchy inside a string
which is not declared as an important dependence is bad.

Now, I also admit that we are not always going to be able to
statically declare every dependence, So....

=======

I think that the above concept of using heirarchy by convention to
have an app locate it's files would be fine as long as we could
statically determine (i.e. by looking at the import table and NOT
running the app) WHICH version of the 'heirarchy conventions' the app
is using.

For example, you're saying above that it's going to open
"/app_resources/..." to get at it's files, presumably then it's going
to open some other path to get at some other information, like perhaps
system configuration data in "/etc" or something like that. I believe
it's important to encode into the app information about which version
of these conventions the app is expecting.

The reason I think this is important can be demonstrated if you look
at Plan9 and VSTa-ish mounting. If I write a program in Plan9 which
uses "/dev/mouse" to talk to the mouse, it dosn't tell the world that
it depends on /dev/mouse being mounted correctly, you just have to
know that ahead of time. If we later come up with a cooler "/dev/moo"
to replace /dev/mouse, and you run an app, you never know which one
needs to be mounted, so you end up with both mounted for
everything. If you need to change the protocol or format of
/dev/mouse, there is no way for the system itself to determine which
apps are expecting the old version of /dev/mouse or the new version.

As an example, if a plan9 or VSTa program published (passively, in
some form of import table) the following information, we could easily
build the private pathname space for that app in a uniform way, so the
developer could use the "heirarchy by convention" because we
established the source version dependencies:

  HAFFF556880-0000 (my_app_data) -> /app_resources
  AB56AF7281A-BC31 (mouse v1.0) -> /dev/mouse
  0110378AB01-C810 (fstan v1.2) -> /etc/fstab

Now the app can use the heirarchial string paths if it wants, but the
local path is built based on requirements that the app publishes.

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