OFF: Extensible File System

[Mike Prince]

On Wed, 9 Nov 1994, Francois-Rene Rideau wrote:

> > I'm milling over the idea of having names for objects of up to 128 bytes 
> > long.  If you want speed in lookup try to give them all 4 byte long names 
> > and have a quick lookup list.
> Well, let's not specify it in the OS, but let it be protocol-dependent.
> Local objects use local pointers; other objects are used through local
> handles and local gates. Example gate: a (IP_address,port) handle -> remote
> gate mapper. A handle is obtained by giving IP address and port; sub-objects
> The underlying idea is: anything is an object. Don't overformalize them.
Yes, the name can be translated by an OS into a more convenient handle 
for internal usage.  I was thinking that each Tool Box would have a list 
of other Tool Boxes it would reference (along with maybe some usage 
information).  When a Tool Box in imported into a work space the list 
references are resolved into a jump table of the native OS.

> > Half-baked idea: Have each domain have a primary object name server, with 
> > an alternate named as well.  The name server offers the suggestion of 
> > where an object is.  Requests to that workspace can then be bounced if 
> > the reference is not correct.
>   Full-baked idea: there are hierarchically organized servers; there can be
> several different hierarchies for several different kind of objects.
>   Some kinds of objects may ask for "double-direction" links: every pointer
> has a back pointer, so that the pointing object may be notified changes by
> the pointed one...

Hierarchies are dangerous.  Chop off the head and...

That's why internet (for the most part) is not a hierarchy, it was 
designed to be kind of fault tolerant for when WW III rolled around.

I'm going to go back to the topic at hand though.  As Jecel has pointed 
out we can discuss technical issues till we're blue in the face, but what 
we really need to know is our ultimate goal?

So, what are TUNES goals, anyway?

Mike