[Gdal-dev] RFC 10: OGR Open Parameters
dron at ak4719.spb.edu
Wed Mar 14 13:12:02 EDT 2007
On Wed, Mar 14, 2007 at 11:36:11AM -0400, Daniel Morissette wrote:
> If no third party drivers exist then perhaps backwards compatibility
> is a non-issue, but your RFC refers to third party drivers, so I
> assume that you meant by that that some do exist. That's why I asked
> for a number... to estimate the impact of breaking backwards
Compatibility issues should be mentioned because we need to be informed
of the number of issues introduced by the proposed changes. Independent
driver authors may express their opinions on the subject, otherwisse we
may consider that there are no objections against proposed breakage.
> I just realized the problem you may be referring to. I think the
> solution is that both versions of OGRSFDriver::Open() should be
> virtual methods (but NOT pure virtual) and the default implementations
> would be:
> OGRSFDriver::*Open( const char *pszName, int bUpdate=FALSE,
> 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 );
> OGRSFDriver::*Open( const char *pszName, int bUpdate=FALSE )
> /* This method is deprecated. Return NULL by default.
> * If a driver implements this virtual method then the driver's
> * implementation will be called instead
> return NULL;
> Then OGR drivers are required to implement only one of the two
> methods. Leading to two possible scenarios:
> 1- Driver implements old Open() method. Calls to the new method are
> automatically rerouted to the driver's implementation of the old
> Open() by the OGRSFDriver::*Open( const char *pszName, int
> bUpdate=FALSE, char **papszOptions /*= NULL*/ ) implementation above.
> 2- Driver implements the new Open() method. Since the method is
> virtual, the driver's implementation takes precedence over the default
> implementation and the driver's own Open() is called.
> Of course for this to work it is assumed that OGR will never attempt
> to call the old Open()... i.e. that it will always pass the
> papszOptions argument to Open() calls. Um... perhaps that's where my
> proposal breaks. :(
Actually my idea is to keep number of methods as small as possible.
Personally I do not like duplication of methods without real necessety.
So I am calling for feedback on above problem: is there anyone, who is
interested in keeping the OGRSFDriver::*Open() interface untouched?
Note, that binary interface will be broken in any case.
Andrey V. Kiselev
More information about the Gdal-dev