[Gdal-dev] RFC 10: OGR Open Parameters
dron at ak4719.spb.edu
Wed Mar 14 08:44:38 EDT 2007
On Tue, Mar 13, 2007 at 10:03:44AM -0400, Daniel Morissette wrote:
> Do we have an idea of how many third party OGR drivers exist that
> would be impacted by that change? (i.e. not counting the drivers that
> are in the GDAL SVN repository).
This change is unavoidable, because OGRSFDriver::Open() is pure virtual
method. Fortunately it is pretty trivial to fix the driver, so I do not
see any serious problem for third-party drivers, if such exist.
> Actually, could we not avoid any backwards compatibility issue by
> playing with the fact that the three Open() methods are virtual?
> The base classes could define a default implementation for the new
> method that just maps the call to the old method without the
> papszOptions, e.g.
> OGRDataSource *
> OGRSFDriverRegistrar::Open( const char * pszName, int bUpdate,
> OGRSFDriver ** ppoDriver,
> char **papszOptions /*= NULL*/ )
> /* Map this call to the old/deprecated GDAL 1.4.0 Open() method
> * for drivers that do not implement the new Open() method added
> * in GDAL 1.5.0+
> return Open( pszName, bUpdate, ppoDriver );
> If I'm not mistaken, this way old drivers would continue to work even if
> they do not define the new Open() method... and upgraded drivers that
> override the new Open() method could take advantage of the new
> papszOptions feature.
Sorry, but I do not understand the point here. OGRSFDriver::Open() is
the method that should be fixed in drivers because it is pure virtual.
How new OGRSFDriver::Open() should be declared? Should it be pure
virtual as the old method? Then drivers will need to implement both old
and new ones. If it will not be a pure virtual, then drivers still need
to implement the old Open() method, even if they want to go with new
style Open() call only. Please, correct me if I wrong.
Andrey V. Kiselev
More information about the Gdal-dev