Hi Sukender, On Wed, Jun 1, 2011 at 2:00 PM, Sukender <suky0...@free.fr> wrote: > Well I've read your posts and I must admit I'm a bit disapointed because > proposed changes seem rather radical to me, and implies some features will be > dropped/reduced...
I'm striving to find a good balance between extensibility and flexibiity and complexity of the implementation and interface. It's very easy to get carried away at try to solve too many problems in one place and end up with a system that might server the needs of small number of power users but be too complicated for the majority of users to use easily for their needs. We also have to maintain and document and support the API's we come up with, the more complex they are the greater the burden. >> For the existing UserData and DescriptionList I'm currently inclined >> to hardwire this into ValueContainer as getUserData() and >> getDescitionList(). This is a bit clunky but it'll be less >> complicated trying to adapt both of these into osg::Object. > > I did not understand why you hardwired userData and descriptionList instead > of letting them be metadata as any other. I don't think this is less > complicated. On the contrary, I feel we must "factorize" code as much as > possible. And this seems akward to me because this forces to have more lines > of code, and thus have more things to debug. I feel more confortable with > less methods and less lines of code, don't you? My reason to provide the UserData and Descriptions list hardwired is three fold - backwards compatibility is much easier when the data strucutres are mapped 1:1, compatibility with older files is much to achieve when the same granulatiry is kept, and finally I I found the solution that you came up with a real cludge - it wasn't easy to read and follow what was going on, it is was possible to break it due to the hardwiring of the names not being protected. > BTW, moving descriptionList availability from Node to Object seems not a good > idea as we're trying to make them disapear. However this may centralize > metadata to one place, so why not, as long as deprecation is clear and > explicit...? This is subject to discussion! It's all just access methods, the Descrptions list will be available via osg::Object no matter what solution we go for, it's just whether we have public accessors for it that make it convinient to use. Originally I had felt that we should probably not be encouraging use of UserData and the Descriptions list, but now I'm not sure they do any harm, and if this functionality is exactly what you wanted in the first place then any other access to it other than through the current conience methods will be more awkward to use. I now feel there is little harm in keeping this methods available and making placing them in osg::Object, there is no memory overhed, it's more consistent. >> The idea of having a ValueBase class which only provides the >> Referenced class and a local clone() seems rather too minimal. Object >> has clone functionality built into it and hooks into the OSG's >> serializers > > I'm quite in favor of using osg::Object as a base for metadata, especially > for serialization. > > But the fact it already stores a name is problemetic when you want your data > to be indexed by name, or if you wish your data be put in a database backend. > For instance, using a map would require names duplicaion (one in the map, one > in osg::Object), or a strange map<string*, Object, string pointer compare> > thing. > > Any opinion/idea on this? Mine is that an osg::Object without name would be > ideal, but this would bring another class! Unless we move the name as a > metadata too? Well this could be a nice idea: some meta names would be > reserved, and especially one for the name, one for userData, and one for > descriptionList. Thoughts? I don't think using a map or equivilant backend is sensible due to the duplication and potential for maps and containers getting out of sync. osg::Object has a Name field, we can't just remove this because it doesn't fit nicely with using a std::map<> in a nieche feature like User data values, we can't just go breaking compatibility for small stuff like this. Given we have to keep the Object Name field it makes sense to use it in the context of user data. >> I also wonder if perhaps ValueContainer and ValueContainerMap might >> just become oen class ValueMap > > I'm not in favor of this. Grégoire and I explicitely made two classes to let > the user choose the container. Especially we wanted to let database backend > (a requirement of some OSG users) be easy to plug. > As Peter told, I guess the "ability to subclass a custom UserDataContainer > implementation" is important. > However I uderstand your point of view on sharing containers, especially > regarding to serialization. So what about something not sharable, but which > user can subclass? I am yet to be convienced providing the ability to subclass from the UserDataContainer is worthwhile. Subclassing from UserDataContainer might be important to a tiny proportion of OSG users. The OSG has got by for over a decade with just Descriptions list and UserData alone, it's not as if this is burning issue for a wide swath of community, so we have to be careful about how much complexity we're willing to introduce to satisfy the wants of a small number of users. I am also not convienced that extensibility of user data might not be possible with the implementation that I proposed and am currently working on. Since UserObjects are just osg::Object's, and it's perfectly legal to share these objects between UserDataContainer's held in the osg::Objects, it should be possible for users to implement their own user data scheme just by subclassing their own container and object types from osg::Object and then assigning this as UserData or as UserObject. This would require them to do an extra get and cast to get access their specialist user data container but this overhead is something only they would need to handle. I'm aiming to keeping the code as simple as we can while providing 95% of users who need the extra capability of user objects with an easy to understand and use solution. As long as the remaining 5% of power users can do what they need if even it's slightly awkward then I'm happy. > The proposal of a vector<ref_ptr<Object> > seems okay for a default > implementation (instead of a map). You're right about trying "to keep the > class count down" (and my implementation is certainely not optimal), but I > keep thinking the container should be customizable and I would keep the > ValueContainer class. I would like to see a concrete example of what funcitonality is needed that requires a user extensible UserDataContainer. We need to spell out the problem that we can't solve easily in any other way. It might well be that can be solved in another way. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
