[vos-d] vobject namespace

[Lalo Martins]

I love it.  In fact I was thinking of something similar recently, I don't
remember the exact context -- but it had to do with mounting remote sites
(nfs? heh) and some distant relation to the OLPC's social mesh.

On Mon, 11 Dec 2006 13:03:47 -0500, 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.


best,
                                               Lalo Martins
--
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
--
personal:                              http://www.laranja.org/
technical:                    http://lalo.revisioncontrol.net/
GNU: never give up freedom                 http://www.gnu.org/