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

On Wed, Dec 02, 1998 at 06:48:42PM -0600, The Doctor What wrote:
> > 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");
>
> I have a question then, does the first example imply that
> "my_instance_resource" is some sort of registry? I'm not keen on that
> unless this registry is very dynamic, strongly typed, network transparent
> and has various data integrety verification methods.

The implementation sitting on the other side of the API is
irrelevant. The important part is that the application isn't
responsible for composing the path, because if it is, then it just
encodes more information which only has meaning by 'convention'.

I assume by registry you are making reference to something similar to
the windows registry. My biggest problem with the windows registry is
that items in the registry have no connection with their 'owners' on
disk. Such that you can lose registry information, or lose file
information, and there is no way to know that you lost one and not the
other. I think we are both thinking along the same lines about where
this kind of information needs to be stored.

> > 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.
>
> So I have a question: To what level do we want a user to be able to
> browse all the structures? Should there be something like a mount point
> (aliased server, namer location, whatever) that can give you access to all
> the functions, from the shell (i.e. from the VFS)?
> VSTa$ /lib/printf ( "%s", "Narf?" )

It's interesting that you bring this up. Most of my thoughts have been
to go away from the non-typed path space and instead rely on stronger
typed structures.

Picture this stark difference between binding done with shlibs, and
binding done with file resources on UNIX.

With an shlib call, the app explains which version of the shlib it
expects the call to come from. Even if you don't have the exact
instance he wanted, you know what he was expecting and can provide a
work-alike.

When a file resource (say /etc/fstab), you don't know which version of
/etc/fstab the app was expecting to see. If somewhere in between when
the app was compiled and now we changed the layout of /etc/fstab, one
would think it wouldn't be too hard to just emulate the old layout for
the old apps. Except that with open("/etc/fstab"), no information is
conveyed about which "/etc/fstab" version the application expected to
see.

So to answer your question, binding libs (or anything) into the
pathname space, is fine if you have some reason you want to do so, as
long as when you write some perl script or something you have the
system preserve information about exactly what instances/version you
were expecting to be bound into the pathname space so that later it
can be recreated without cracking open the head of the person who
wrote the script.

> Frankly, I love it. Having a strongly typed FS/resources would be a
> beautiful thing (IMO). In addition, to owner, there should be an ACL too.
> This would make life really nice.

I prefer to just let you store arbitrary 'dimensions' of information
on top of resources. I think it's important to establish a system of
ownership, unique naming, and translation between these extended
attributes, but to dictate them ahead of time just walls us into more
static solutions.

> Imagine taking a scsi disk from one scsi controller and putting on it
> another (i.e. change it's physical location) and have the whole thing just
> move cleanly (after all, its identity "storage/Chris' scsi root" would be
> unchange!).

Exactly.. or better yet... imagine installing a 1gb disk and having
the system just say "you have 1gb more space" instead of requiring you
to deal with manually installing items in different physical
locations. Of course information about what physical location(s)
something is stored in should be available, but it isn't necessarily what I want to center around all the time.

> I think process space should be broken in this way too, after all,
> everything in a microkernel is a userspace process. That'd allow
> something like Tandem's Expand.

I don't understand what you mean here... can you elaborate?

> Oooh.... I like. I must be my C++ programming roots saying "Whoohoo!
> Strong Typing!"

I'm just as much a dynamic typer at heart. However, I recognize that
some items inherently are static and some items are inherently
dynamic, regardless of whether you treat them as such.

Much of my desire to treat static requirements as static typed items
is that I don't like the idea that every open("/etc/footab") function
in a program is a point of failure. I'd prefer to be able to static
check all the static requirements of a program beforehand to assure it
can run. That way, the program only has to do complex error checking
and handling for those things which it ADMITS are dynamic cases.

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