[osg-users] Meta-data in core OSG - project started
suky0001 at free.fr
Wed Apr 27 13:22:14 PDT 2011
Your analysis seems fine. However, I must add a precision: In the current design, there is a ValueBase class (actually an empty class derived from Referenced). This way it's a bit easier dealing with values as the base class is not templated. Well, not something enough to change your mind! :-)
I understand your choice, but fear that simple uses may be not straightforward to understand for OSG beginners, or simply for OSG users that don't want/need to have complex systems. So my feeling is "better a simple thing that may be complexified by advanced users, even if it's a bit difficult, rather than a less straightforward system".
As an advanced user, it's a frustration and heartbreak to say "okay, let's go for a system with less features", but there will always be more beginners than experts... don't you think?
However I don't wan't the system to be tied exclusively to simple uses only. Yes, having a database backend may not be that simple, but I want this to be possible. For instance, we're currently coding first things and found it was a good thing to let the container know about its "parent" objects for this DB backend. So the Object::setValueContainer() looks like:
tell the current container we're detatching
replace the current container with the new one
tell the new container we're attaching
I guess some little things like this may help creating a DB backend. And after all, why not having an osgMySQL or osgPostGre later on, as both an out-the-box default DB backend and a model for other ones?
BTW, I think next steps on our side are:
1. Finish the first implementation (almost done)
2. Convert our project to use these new metas, to check everything goes fine.
4. Send OSG modified files on the mailing list (osg-users) for a first review.
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "Peter Amstutz" <peter.amstutz at tseboston.com> a écrit :
> Sorry about that, you sent out the previous email on the weekend and
> didn't have a chance to look at it; when Monday rolled around I had
> forgotten about it.
> Regarding the Value class, I think I understand the difference of
> opinion a little better. Let me present both sides.
> // Option A. Value types are osg::Referenced and mutable
> osg::ref_ptr<Value<int> > v = container->getMeta<int>("foo");
> assert(v->get() == 3);
> assert(v->get() == 5);
> - A value object can be held by many nodes. Changing it in once
> affects all nodes.
> - Similar to how other reference counted elements of the scene graph
> work, e.g. osg::Uniform
> - Value<T> will probably need a parent list to track its owners
> - Awkward to map metadata values onto a database. In addition to
> getMeta() and setMeta(), must derive from Value<T> or come up with a
> callback interface to tie to the data store.
> - Potential for race conditions if a thread changes the contents of
> "value" while another thread is using it
> // Option B. Value types are not refcounted and immutable
> Value<int> v = container->getMeta<int>("foo");
> assert(v == 3);
> node->setMeta<int>("foo", 6);
> assert(v == 3);
> assert(node->getMeta<int>("foo") == 5);
> - A value object cannot be held by multiple nodes. If you want to
> logically share a value across nodes, must store a pointer or id into
> separate table as the value.
> - Similar to non-reference counted elements of the scene graph.
> - Value<T> can be very simple and doesn't need to track or
> backreference anything.
> - Straightforward to map to a database, only need to implement
> getMeta() and setMeta()
> - No race condition concerns.
> Laying it out like this, I could support a design going either way.
> However my instinct is to prefer immutable data structures as a
> rule as they tend to reduce programming errors (especially when
> are involved). I also think the metadata facility should be simple
> easy to extend by implementing a new MetadataContainer class rather
> putting in complicated hook/callback/proxy mechanisms that try to
> I think the next step should be to put together some header files /
> class definitions so that we can discuss the proposed API in
> - Peter
> On 4/27/2011 10:09 AM, Sukender wrote:
> > Hi Peter, hi all,
> > We're working on impementing the meta-data system. We found that
> there was very few feedback, and feel it's a bad sign of inacceptance
> of it... Anyone?
> > Peter, when you told about immutability, it was with a database
> backend in mind, right? If so, I think it may be better not to have
> immutable Values. Indeed, DescriptionList and more generally user data
> may be mutable. So to get this database backend wokring properly, I
> think one should:
> > - Define a "ValueDB", derivate from ValueBase.
> > - Define a "DBProxy", derivate from ComponentContainer (well, we
> renamed it ValueContainer to avoid misinterpretation)
> > - Make DBProxy give ValueDB when getting
> > - Make ValueDB know DBProxy so that modifying a ValueDB will call
> appropriate method in DBProxy
> > - Make DBProxy also accept Value<T> as an input, and convert it to
> appropriate SQL/request/whatever
> > Thoughts?
> > Sukender
> > PVLE - Lightweight cross-platform game engine -
> > ---
> Peter Amstutz
> Senior Software Engineer
> Technology Solutions Experts
> Natick, MA
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users