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

Sukender suky0001 at free.fr
Wed Apr 27 13:22:14 PDT 2011


Hi Peter,

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.
3. Debug
4. Send OSG modified files on the mailing list (osg-users) for a first review.

Cheers,

Sukender
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
> 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);
> v->set(5);
> 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
> everything.
> 
> 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
> 02131
> 
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



More information about the osg-users mailing list