[osg-users] osgDB::writeNodeFile -- no Options?

Robert Osfield robert.osfield at gmail.com
Sun Sep 30 10:57:13 PDT 2007


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 <pmartz at skew-matrix.com> 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 <pmartz at skew-matrix.com> 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
> > > osg-users at lists.openscenegraph.org
> > >
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> > > org
> > >
> > >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
> negraph.org
>
> _______________________________________________
> 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