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

On Thu, Dec 03, 1998 at 06:31:07AM -0500, Gavin Thomas Nicol wrote:
> Ok.This is a bit different to what I was talking about. What you are
> proposing here is more or less that resource resolution be a function,
> rather than being statically resolved. I agree.

Correct.

> However, in the above function, you *still* have to bind to something,
> and have a way for naming that something, and again, I contend that
>
> /app_resources/ja/ui/menu
>
> is as good as a GUID.

If you want a standard heirarchy to store your applications private
information, that's fine. I don't think we should dictate this for all
apps, because some apps will want RDBMS storage, or simple record
storage, or BSP, or some other storage type.

However, I still contend that we're better off naming the "app
resource instance" by using a collection of fields in a flat table,
and using something analagous to a GUID for uniqueness properties.

For example, in this case we'd be storing a flat collection of
heirarchial "mini-spaces", one per app. So instead of letting the app
arbitrarily place itself inside the physical namespace:

  /usr/local/netscape/ja/ui/menu

We place it's "mini-space" inside the flat logical namespace:

  Instance ID Category ID Name Ver Mini-Space Name/type
  I-1 C-1 Netscape 4.03 MS-1/HEIRARCHY
  I-2 C-1 Netscape 4.05 MS-2/HEIRARCHY
  I-3 C-2 Yellow Pages v1.0 MS-3/DB

And it's local resources can be stored within the mini-space with a
standard heirarchy if the author so choose like:

 Mini-space contents: MS-1/HEIRARCHY
 ja/ui/menu
 en/ui/menu

 Mini-space contents: MS-2/HEIRARCHY
 ja/ui/menu
 en/ui/menu

Or if it suited the author's purpose better purpose better:

 Mini-space contents: MS-3/DB
 table "listing" columns = name, address, phone

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