[osg-users] Meta-data in core OSG - project started

Peter Amstutz peter.amstutz at tseboston.com
Wed Apr 27 11:17:20 PDT 2011

Sorry about that, you sent out the previous email on the weekend and I
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 places
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 a
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 general
rule as they tend to reduce programming errors (especially when threads
are involved).  I also think the metadata facility should be simple and
easy to extend by implementing a new MetadataContainer class rather than
putting in complicated hook/callback/proxy mechanisms that try to handle

I think the next step should be to put together some header files /
class definitions so that we can discuss the proposed API in specifics.

- 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 - http://pvle.sourceforge.net/
> ---
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA

More information about the osg-users mailing list