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? >> ConstructorFunctionWrapper >> ConstructonFunctionFunctor >> ConstructorFunctionComponent > rename ConstructorFunction* to Constructor*? Are there other ConstructorThings? >> The host's factory (i.e. from Host::getFactory()) > > In order to create new objects attached to a particular Site, you use > the Factory object on that site (Hosts are a special type of Site.) > This is the basically the same as s4 with Site::createVobject(), but > separating the Factory out to a distinct Vobject. > 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? >> DataTypeWrapper >> ParentChildLinkWrapper >> ClassWrapper etc. 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. Or DataType is a subclass of DataTypeBase which overloads DataTypeBase to add the Wrapper stuff? (Maybe it also inherits from a Wrapper base class?) 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. The second "use level" is defining new types, primarily component types. And then, beyond that, users would maybe need to deal with Interface and Implementation objects. I.e. maybe adding support for a new language or something? Or ever? ... >> What does it mean to append children to the local host? I am guessing >> this is so the object doesn't get destroyed (by reference count/garbage >> collection), and so you can also obtain it by name later? Do all > > The local host is a special site. Sites now have a root child list > which is like a root directory. > >> objects need to be added to the local host (like they were all children >> of the local site in s4)? And if so, why not do that automatically when >> created? > > When created, vobjects must be associated with some site (such as the > local host). The intention is that in order for the vobject to be > persistant, it must be connected to the vobject structure so there is a > path from the root to the vobject. Vobjects which are not connected to > the root are not persistent. > So a factory that you obtain with Host::getFactory() is not associated with the local host really? Could we integrate the adding of a Vobject to the local host into the creation of a vobject (as above wrt. factory). 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... Reed _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
