Hi Robert 2010/1/22 Robert Osfield <[email protected]>: > The name ObjectRegistry is potentially confusing for users whien they > start looking at osgDB, so I'l like to come up with a new name that > doesn't overlap with osgDB::Registry. ObjectWrapperManager perhaps? > I'm struggling to think of a better name. > I want to refactor the old DotOsgWrapper support into osgDB::Registry > to follow the decoupled approach we already have with ObjectRegistry, > so pull out DotOsgWrapper methods in Registry out into their own > DeprecatedDotOsgWrapperManager class. Then Registry would have a get > method for both the ObjectWrapperManager and the > DeprecatedDotOsgWrapperManager, and the macro's would then redirect > them selves to these new classes.
I believe the name ObjectWrapperManager and DeprecatedDotOsgWrapperManager is good enough at present. Maybe in the future we could rename the first one to DotOsgWrapperManager and ObjectWrapper to DotOsgWrapper, to indicate that it's the recommended .osg wrapper manager. >> class OutputStream; >> class AsciiOutputStream : public virtual OutputStream, public ascii_ostream; >> class BinaryOutputStream : public virtual OutputStream, public >> binary_ostream; >> >> And in writeNode() function of the ReaderWriter: >> >> OutputStream* os; >> if ( isAsciiOption() ) os = new AsciiOutputStream; >> else os = new BinaryOutputStream; >> os->writeObject( ... ); >> >> It seems to be better than just do both tasks in a huge OutputStream. >> What's your opinion? > > It does seem a more nature approach to take. Could you have a bash at > implementing this and see how you get on. I just created two heritable OutputIterator and InputIterator base classes encapsulating the std::ostream and std::istream in the osgDB namespace. And the binary and ascii successor in the osgPlugins/osg subdirectory. This new mechanism reduces the output/input classes' size and make them a little more agile, for instance, new XML support could be easily added with a XMLStreamOperator header later. I also changed some osgDB header macrodefinitions from something like H_DATATYPES to OSGDB_DATATYPES, to keep the code clean. All updated files are included in the attached tarball, based on the latest SVN. Please have a look at them to decide if the modifications are acceptable. > What I'd like to see is an approach like I took with the .ive plugin - > it does mean slightly more code in terms of checking for whether to > abort a read or write compared to using exceptions, but it'll be less > code than a conditional compile approach which tries to do both, and > far easier to maintain. OK, I'll take a look soon. The newly added OutputIterator and InputIterator, which focus on the stream I/O only, may also help when checking and aborting user operations immediately if failed. > If you wanted could organize a little section on the history side then > please feel free to ping me and others for it. With the nature of the > project I think it's healthy to know that it's not been developed by a > big corporation or a bunch of engineers from a different world. It would be useful, I'd like to think of that carefully. :) I'm working on the osgParticle and osgText wrappers now. After that I would write a small tutorial to help the public quickly learn the new format and join it if they want. All the work are hoped to be finished this week. :) Wang Rui
osgDB_And_Plugin_modified.tar.gz
Description: GNU Zip compressed data
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
