[Gdal-dev] RFC 10: OGR Open Parameters

[Andrey Kiselev]

Daniel,

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.

Best regards,
Andrey


-- 
Andrey V. Kiselev
ICQ# 26871517