Re: [vos-d] vobject namespace
Peter Amstutz wrote: 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. OK, so / is the root object, not the site, (and if you ask it to list-children you only get objects in the root, not all) and /foo is an objet that's properly in the root, but /$abcde is bypassing the filesystem and accessing directly by ID? No way to get *all* objects on a site? (Might be useful, not for remote access but when working with COD files, say) 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!) Right, well we already do this sometimes, it's just all ad hoc. Actually I like the ad-doc nature, one nice thing about VOS is that it's not neccesary to have a conforming structure, so long as you have the right references to the right vobjects with the right types in the right places. 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. Do you think that this problem is actually a feature? If you want to move objects out of the normal tree but still keep them around. I.e. if it garbage collected you'de have to move the objects to /tmp etc. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] vobject namespace
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
Re: [vos-d] vobject namespace
How is this different than the way things currently are? 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? 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 ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [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@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] vobject namespace
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 ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [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 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
