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

On Wed, Dec 02, 1998 at 10:58:34AM -0800, David Jeske wrote:
> 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.

Well...while it's true that the actual microkernel implimentation doesn't
require (much) of this kind of discusion, implimenting the Operation
System as a whole will benifit from a well thought out central concept.
VSTa (for most of us, both theory and practical VSTa-subscribers) is a
chance to do things better than UNIX.

Andy's first working versions showed that VSTa could be *much* more than
"Yet Another Unix". Why not take this concept and run with it?

Anyway, on to the main show...

> 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.

> 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?" )

> 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?

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.

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!).

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.

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

Ciao!

-- 
"Always do right.  This will gratify some people and astonish the rest.""
	-- Mark Twain
The Doctor What: <fill in the blank>        http://www.gerf.org/~docwhat/
docwhat@gerf.org                    (finger docwhat@gerf.org for PGP key)