Re: [vos-d] s5 site ids
Yeah, I think we should push and see how effectively we can really use VOS for and develop tools and practices for that. For example, if we're working on the UI client and want to put the available types in a menu. You could write a for loop that goes through the types and puts each thing in the list. Or you could write a tool that takes any Vobject and lists its children in a menu, and updates the menu for changes, etc. If you can get the tool right, you can reuse that in a bunch of other places in the UI. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
You've got it. Setting up aliases based on prefix at the top of the XOD
file was exactly the solution I had in mind to the verbose-site-ids
problem. Similarly in the code generator we just need to emit a macro
which hides the scary site namespace.
On Tue, Feb 12, 2008 at 06:04:50PM -0500, Reed Hedges wrote:
>
>
> In VOS it in fact would be easy to build a little tree of the types with
> different names to make them easier for people to work with, while
> keeping their real names hidden.
>
> So you can make an object like "/t" and select out the specific top
> level versions used from the containers ("namespaces"?) with the big ids.
>
> E.g.
>
> /t/vos -> /vos:0011223344556677889900aabbccddee/vos
>...Has various children for core types...
> /t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
>...Has various children for 3d types...
> /t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
>...Has various children for custom types...
>
> /foo type="/t/mytypes/foo"
> /bar type="/t/a3dl/object3d"
>
> Maybe we even enshrine a container like /t or /_types as standard place
> to put the "working set" of types, as a convention that all user
> interfaces use, and so when they are telling a user what the type of a
> vobject is, they can just strip off the prefix, or when preseting the
> user with a list of possible types, just provide a listing (or tree
> view) of the children of /t, etc.
>
> Or a UI can just look at the type definition to get a user friendly type
> name.
>
> But OK, in the general case, we need to come up with ways like this to
> help users navigate vobjects, whether in a particular application or in
> VOS stuff like this, without having to put a lot of special stuff in the
> user interface clients.
>
> Reed
--
[ 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
Re: [vos-d] s5 site ids
In VOS it in fact would be easy to build a little tree of the types with
different names to make them easier for people to work with, while
keeping their real names hidden.
So you can make an object like "/t" and select out the specific top
level versions used from the containers ("namespaces"?) with the big ids.
E.g.
/t/vos -> /vos:0011223344556677889900aabbccddee/vos
...Has various children for core types...
/t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
...Has various children for 3d types...
/t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
...Has various children for custom types...
/foo type="/t/mytypes/foo"
/bar type="/t/a3dl/object3d"
Maybe we even enshrine a container like /t or /_types as standard place
to put the "working set" of types, as a convention that all user
interfaces use, and so when they are telling a user what the type of a
vobject is, they can just strip off the prefix, or when preseting the
user with a list of possible types, just provide a listing (or tree
view) of the children of /t, etc.
Or a UI can just look at the type definition to get a user friendly type
name.
But OK, in the general case, we need to come up with ways like this to
help users navigate vobjects, whether in a particular application or in
VOS stuff like this, without having to put a lot of special stuff in the
user interface clients.
Reed
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
On Sun, Feb 10, 2008 at 08:18:05AM +, Lalo Martins wrote: > Also spracht Reed Hedges (Sat, 09 Feb 2008 10:35:25 -0500): > > The new type IDs are still bothering me a bit too (among other things, > > like the code namespaces). A huge advantage of the old user-invented > > type names is that they were natural to understand and easy to remember. > >We're going to have to do a lot of cutting and pasting, and when we > > get one digit wrong, will be tearing our hair out over it. (Or the only > > option will be to use the GUI tool.) This is a result of the design decision to have the interfaces be reflectively described using VOS. Since the API is described using Vobjects, and the vobjects must be located on a unique site, references to vobjects must include site identifiers. It's worth pointing out that XOD is extremely low level and not really intended as the primary way of editing vobjects, but it is all we've got at the moment. I am thinking about writing some tools that will take care of some of the house cleaning task like fixing paths and assigning identifiers to individual vobjects in order to transform a partially specified file into a fully specified one. > AIUI from IRC conversations, the site IDs won't actually be visible to > the application programmer later on; we'll deal only with IDs like "/vos/ > core/StringProperty". (I'm not sure about the code namespaces, but I > hope some simplification is intended there too ;-) ) Peter has actually > told me a few days ago that side IDs being required for the type > attribute in XOD is "a bug". For now, we cope; the IDs are extra work, > but not really a killer. Actually it is the other way around. The bug is that the type attribute does *not* presently require a site id, due to a quirk (well really a hack) in the way it uses the type attribute string to look up which component implementation to use. It ought to require the site id so that it unambigiously refers to a specific vobject class type. > > Also, what in the HelloWorld example is autogenerated and what isn't? I will have the code generator insert comments into the files so you know the difference. > Each Namespace "world" gets a "world.hh" with wrappers and interfaces, > plus "worldComponents.hh" and "worldComponents.cc" with components. > It's not yet 100% clear to me when "user" code should #include "x.hh" > or "xComponents.hh"; I believe if you need to create a new instance of > something, you need "xComponents.hh", otherwise "x.hh" will allow you > to > work with existing objects. Each "xComponents.hh" already > #includes "x.hh", so you never need both. As you said, "x.hh" gives you the interfaces, "xComponent.hh" gives you the implementations. > And each Class or Lambda "foo" gets its own "foo.hh" and "foo.cc", where > you'd put the concrete implementation. These don't get overwritten if > they exist, since they will contain handwritten code. (Which makes it a > bit of work to cope with API evolution, but you can always point the > generator at a new, empty directory, then copy-paste.) One way to manage this would be to put in comment guards that indicate a certain section of the file is replaceable, and update that section for API changes. > This naming pattern unfortunately means you can't have two > "things" (class, function, namespace) on the same directory. Whether > that can be a problem is illustrated by helloworld itself: if you write a > "Library" to contain only one single class, the most natural naming would > be for Library, Namespace and Class to have the same name. Suggestions > on how to fix this are appreciated, I have no idea myself ;-) (Maybe > something like "/helloworld/core/HelloWorld"?) The code generator should probably tack on something to the file name so you get HelloWorldLibrary.cc, HelloWorldNamespace.cc and HelloWorld.cc. -- [ 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
