Hi Paul, Changing Registry API is not such a worry as its not something most users will use directly - most should use writeNodeFile(..) so go ahead a change what you think is appropriate. I'm making a dev release tomorrow morning so it'd be useful to get the changes by then if possible.
Cheers, Robert. On 9/30/07, Paul Martz <[EMAIL PROTECTED]> wrote: > Hi Robert -- I'm getting ready to make this change, and I've noticed that I > need to change the Registry::write*() interfaces. If I change them to match > the read*() functions, then this will not be backwards compatible. E.g., > anyone who currently calls: > > osgDB::Registry::instance()->writeNode( rootNode, fName ); > > ...will now have to call: > > osgDB::Registry::instance()->writeNode( rootNode, fName, > osgDB::Registry::instance()->getOptions() ); > > In the core distribution, at least osgconv requires this change (haven't > checked the examples yet but will soon). Outside of core OSG, this could > affect lots of existing code. > > I'm assuming the same change was made previously to the read*() interface, > so my intent is to go ahead with this incompatible change, unless you advise > otherwise. > > Thanks, > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > 303 859 9466 > > > > > > HI Paul, > > > > Your analysis is correct, the ReaderWriter::Options post > > dates the original read/write*File methods. In the case of > > read*File the Options was added as it was required by users. > > No one until has piped up and pointed at the lack of Options > > parameter in the the > > write*File() methods. Feel free to add them. > > > > Robert. > > > > On 9/19/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Robert -- A couple questions on passing Options into the osgDB > > > read/write methods. > > > > > > First, the write methods (e.g., writeNodeFile, writeImageFile, etc) > > > don't take ReaderWriter::Options as a parameter. Instead, they > > > implicitly pass the osgDB's _options member variable to the > > plugin. Is > > > there a design reason for this to be different from the > > analogous read > > > interface? Or, more to the point, if I added Options as a > > command line > > > parameter to the write methods, would you reject such a > > submission for any a priori reason? > > > > > > Second, looks like the read interface has two methods each for > > > readNodeFile, readImageFile, etc., one taking Options the other not > > > (and getting it from the registry). I assume this was done for > > > historical reasons to preserve backwards compatibility? The > > > non-Options interface was first, and the interface with > > Options came along later? > > > > > > Of course, I'd have to do essentially the same thing if I were to > > > modify the write interface to take Options. > > > > > > (Stumbling across all sorts of fun stuff as I try to create this > > > OpenFlight exporter. :-) > > > > > > Thanks, > > > > > > Paul Martz > > > Skew Matrix Software LLC > > > http://www.skew-matrix.com > > > 303 859 9466 > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > > > org > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
