[osg-users] Meta-data in core OSG - project started
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);
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
- 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.
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
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Senior Software Engineer
Technology Solutions Experts
More information about the osg-users