Am 11.12.2006 um 19:03 schrieb Peter Amstutz: > 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, > What do you mean by "mount" here? A filesystem is not a vobject graph, you'd have to wrap each of its files into a vobject first. Or wait, is this one of the things you could do with the magical virtual s5 vobjects?
> 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. > Really? I thought this was already done this way? But then, I was never really clear on the details of the vobject lifecycle and this "excise" stuff... > 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. > I'm slightly confused. So far, we had the canonical name, based on the direct site-to-vobject link. This was what the whole VOS infrastructure worked with, as well as the VOP/VIP protocols (from,to attributes). Then there was the path name, which was only used at the user/programmer level. Whenever the VOS infrastructure got one of these, it first had to resolve it into a canonical name by following the contextual name/number links from the site. Now, you want to ditch the direct site-to-vobject link (fine by me), and use the $88FA form as new canonical name? Or do you truly want multiple vobject identities, one for each way it is linked into the vobject graph, plus one "internal" ID (whatever that is)? > 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. > Sounds good, except that I'd like to see vos://interreality.org/ core:plugins there... I'm not sure it you care, but I found it useful to distinguish between "role" path elements with a colon, and pure "name" elements without a colon. The first kind indicates what role a child plays in respect to the parent vobject, e.g. "a3dl:position". The namespace reflects the fact that this is a "registered" name for a precisely defined semantic concept. The second kind is arbitrary, and signifies nothing except membership. You find this mainly on the site and the sector, as "Karsten" or even "08154223", since often users don't care about vobject names and let VOS generate it. > 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. > Right... you could then use the hard link count to find out when a vobject is no longer needed, and trigger the excise thing. Maybe this could also help somehow in handling "temporary vobjects", i.e. avatars created manually on the site by a client or a factory. So these vobjects would be linked to the client's site only, and loose this link on disconnect, which in turn triggers removal.... Just a quick thought. > 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. > Well, at least something stays the same :-) Regards, Karsten Otto (kao) _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
