On Sat, Mar 01, 2008 at 04:06:09PM -0500, Reed Hedges wrote: > > I've updated http://interreality.org/wiki/S5 with this information. > Peter, can you please check it and fix it if anything is inaccurate? I > did elide some of the minor details, just in the interest of clarity. > > Some minor comments below about naming things to be less confusing to > think about if you want... > > Also it might help people understand how VOS works if the libvos code > was seperated a bit into directories or the files were named according > to use 'layers'... E.g. I don't think people need to the code > generation infrastructure much?
The current scheme of dumping everything (autogenerated or not) into one directory is something I would like to change. You need to use the code generation utilities to define new classes, so it is a key piece of the s5 design, unless you mean for other people working on libvos specifically. > >> ConstructorFunctionWrapper > >> ConstructonFunctionFunctor > >> ConstructorFunctionComponent > > > > rename ConstructorFunction* to Constructor*? Are there other > ConstructorThings? Yea, that could be renamed. Although I believe that constructs Component objects, so a better name would actually be ComponentConstructor (which would be just as long as the current name, but slightly clearer). It is a lambda type, which means it binds to a native function rather than a class, which is helpful in these edge cases when you need to bootstrap the system (i.e. aquire/create a few objects) before you can work in purely object-oriented terms. > Would it make sense to hide all this (Factory/Constructor/Implementation) > with a few more > convenient static methods in Host, at least to address the most common needs > of creating > vobjects. (While users who need to do more advanced things like add new > types etc. can access > the factory.) We ended up doing something similar in S3/S4 I think? Yes, there should be a simplified interface. On the other hand, object construction is inherently more complicated than the usual "new Foo()" because you have to supply the Host, Site and some number of component types that will be created as part of the vobject. > I still think it would be easier for people to use VOS if the wrapper > classes had "plain" names, and the thing being wrapped had the funny > name. E.g. > > DataType is the wrapper for DataTypeCore or DataTypeImp or DataTypeBase. The same reason I stated before, I want to avoid confusion between having a reference to an object and having an actual copy of the object. We could call them "Handles" instead of "Wrappers" (so you would access objects through DataTypeHandle or VobjectHandle) which might be clearer. Changing the name would be a hassle, though (search and replace across dozens of files). This is something of an artifact of how the C++ binding is implemented (due to the limits of C++) and can be done more cleanly in languages with better reflection facilities or dynamic typing. > I.e. it seems to me that at the most basic, and starting/newbie "use > level" users just need to work with wrappers. Through the vobject > wrappers they find children, access component wrappers, etc. So this > "use level" should be the simplest and hide some of the complexity > that's going on. Well, the hope is that eventually newbies won't be using C++, they'll be using Python or C# or some other more civilized language. > So a factory that you obtain with Host::getFactory() is not associated > with the local host really? The factory creates objects for the host it is located on. So if you have a handle to a remote factory object, you can create objects on that remote site. You could do this in s4, except that the concepts of host, site and factory have been split up (to allow for distributed/clustered sites, eventually) instead of all being under the site concept. > Could we integrate the adding of a Vobject to the local host into the > creation of a vobject (as above wrt. factory). My experience has been that having an object register itself with a manager in the constructor is a bit dicey, in particular it tends to break when subclassing is involved, where the superclass constructor runs before the subclass constructors have had a chance to fully initialize the object... The factory should be adding the object to the correct site, though. Just to clarify: A site is a collection of vobjects. Some or all of a site can be cached or replicated across many computers. A host represents a single computer (actually, a specific OS process) Sites are located on one or more hosts. Hosts can have more than one site. A host is a special type of site. To create a vobject, you need to have a site to create it on. To be able to add components, you need to have a binding from an abstract VOS class to a concrete class in an actual language on an actual host. This is what the "Implementation" vobject represents. > I.e. I'd like creation of Vobjects on the fly to be easier... it really > should be even easier than in S4, which is sort of complex and hard to > remember what function to use when... I'm open to specific suggestions. Also, because libvos is itself being specified and generated from the CoreSchema.xod file, some of the design decisions have been influenced by the capabilities (and limits) of the core schema and code generator up to this point. As that matures, so will the ability to specify a more natural API. -- [ 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
