[vos-d] vobject namespace

[Peter Amstutz]

On Tue, Dec 12, 2006 at 07:23:05AM -0500, Reed Hedges wrote:
> 
> How is this different than the way things currently are?

It's not, except that s5 uses 32 bit identifiers as the "canonical name" 
of a vobject rather than arbitrary strings.

> Are you proposing to require that all objects except one special root 
> have at least one parent?  Or just to encourage that practice for most 
> objects?

Requiring it.  This allows us to have one unified namespace instead of 
lots of little subtrees hanging off the site root.  Also I think this 
makes it easier to ultimately start defining recommendations for 
organization (i.e. where does vobject reflection go, configuration, 
worlds, hypervos pages, etc...  it may well end up looking like a unix 
filesystem!)

Also, by forcing everything to start from one particular root, we can 
garbage collect the site by occasionally running a mark-and-sweep 
algorithm to sweep up cruft in the form of discarded vobjects.  If 
you'll recall, long-lived sites (interreality.org hypervos site, and the 
3D worlds using the irc bridge) have a way of steadily gaining vobjects 
that weren't connected to anything and never deleted.  Obviously this is 
partially a programming problem that they weren't freed properly, but it 
would be a great advantage to be able to automatically sweep up these 
loose vobjects.

> Reed
> 
> Peter Amstutz wrote:
> > I just wanted to float another idea for a change in s4 to s5.  
> > Previously in s4, there was no well defined "root" of the vobject tree.  
> > Or rather, there was the site root, but listing the contents of this 
> > root would get you every vobject on the site, which was rarely what you 
> > wanted.
> > 
> > I'm thinking that it would be useful to have a well defined root, 
> > similar to the unix file system root, and for vobjects on the site to be 
> > treated sort of like inodes.  This has a few advantages: it is simpler 
> > to "mount" conventional filesystems onto the VOS namespace, and it is 
> > easy to identify "named" (accessable via the root) and "unnamed" 
> > objects, and to garbage collect the latter since we found that 
> > long-running sites had a tendency to build up cruft in the form of 
> > discarded unlinked vobjects.
> > 
> > A vobject would now be describable as either a literal identifier like 
> > vos://interreality.org/$88FA3483 or with a path like 
> > vos://interreality.org/worlds/blocks.  The former would be used 
> > internally, the latter would reflect the human and programmatic layout 
> > of a VOS site.
> > 
> > VOS reflective structures would be linked as branches off the root, such 
> > as the list of vobject types, and sitewide configuration parameters 
> > (like what plugins are loaded).  So you could browse 
> > vos://interreality.org/types/namespaces/core to get a list of all 
> > vobject types present in the "core" namespace.  Or you could browse 
> > vos://interreality.org/etc/plugins to get a list of plugins.  This would 
> > be well defined so that these structures are available on any site.  
> > 
> > Child links would be like hard links in a Unix file system, except that 
> > we'll maintain the "parent" list, so you can actually tell who's 
> > pointing to a particular vobject.  I suppose in this scheme a hypercard 
> > would be like a symbolic link.
> > 
> > The basic model of the child list as associative list would be 
> > unaffected.  Also, this is extremely easy to implement, since the code 
> > for parsing and following paths is more or less the same either way.
> > 
> > [   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
> > [Lead Programmer][Interreality Project][Virtual Reality for the Internet]
> > [ VOS: Next Generation Internet Communication][ http://interreality.org ]
> > [ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > vos-d mailing list
> > vos-d at interreality.org
> > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
> 
> 
> _______________________________________________
> vos-d mailing list
> vos-d at interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20061212/63ab4bba/attachment.pgp