[osg-users] Node::Description into a generalized property mechanism?

[Ulrich Hertlein]

Hi Chris,

have you noticed the "Suggestion: Add components in nodes (aggregation)" thread from 
around 29/10/2009?  It deals with something similar, namely to introduce something like a 
osg::KeyValueMap (derived from osg::Referenced) that can be attached to osg::Objects as 
user-data.  (These could also serialize to and from files.)

I would also like having a general purpose key/value object so that loaders can attach 
data to images for example.

osgDB::Options could use this as well instead of getOptionsString() (which is used by 
heaps of plugins that do a find('myOption') on it) and getPluginData() (which is a 
string->void* map).

Of course this doesn't yet solve your problem with there being only one user-data field. 
The problem I see with adding a new meta-data field to objects is what happens with name 
conflicts when two plugins/programs want to use the same 'key' name?  In that case we'd 
need to introduce namespaces (like a map of string->KeyValueMap) so that each plugin can 
have its own key/value map?

Thoughts?
/ulrich

On 30/11/09 5:09 AM, Chris 'Xenon' Hanson wrote:
> Mattias Helsing wrote:
>> Is there a reason to why you don't use setUserData(osg::Referenced*) ?
>> If you provide the proper read/write routines for your osg::Referenced
>> derived class it would also persist across .osg file writes/reads.
>
>    Because there's only one UserData, and in my library code that I might share with
> others, I try to avoid taking exclusive use of some asset that others might be used in
> their application code.