[Gdal-dev] Re: RFC 10

[Mateusz Loskot]

Andrey Kiselev wrote:
> On Sat, Nov 10, 2007 at 11:56:24AM +0100, Mateusz Loskot wrote:
>> I'd like to ask you about your plans regarding the RFC 10
>>
>> http://trac.osgeo.org/gdal/wiki/rfc10_ogropen
>>
>> Recently, I added new driver - GeoJSON - to the OGR set and in this
>> driver I follow your concept from the RFC but input parameters are
>> "passed" to Open() call as environment variable.
>>
>> I believe it would be good to have RFC10 implemented for 1.5.0 so I'm
>> willing to help in this. Could you tell me if and where I could be
>> helpful?
> 
> Hi Mateusz,
> 
> I am CC'ing to list to initiate a new discussion of RFC 10.
> 
> Actually I am thinking about revoking the RFC 10 because of two reasons.
> In first of all it looks like it will not be adopted in the current form
> due to the API changes it needs.

Andrey,

I understand.

> The second reason came to my mind when I better thought out the problem.
> It is a problem with GUI applications.  GDAL has a possibility to
> automatically determine input file format without user specification,
> that is why we can't pass driver specific open options in the Open()
> call. Typical scenario for GUI applications is the following: show the
> open dialog to choose the file name --- at this stage we don't know the
> file format yet and can't put driver specific switches on that dialog.
> After file selection stage we can show the option dialog, but the
> problem is that we don't know the file format, and also we do not have
> a way to interrupt the GDALOpen() call to pass our options there.

It makes sense to me.

> Note that non-interactive CLI applications does not have this problem
> because of their non-interactivity :-). We will need to run such an
> application twice: the first run to determine file format and the second
> run to perform our task using correct format specific options. Or we
> should know the file format from the third part.
> 
> I see two ways to solve this problem.
> 
> 1. Introduce the callback function which will be called in the Open()
> method and return back driver specific open options --- GUI dialog can
> be shown to user here.

It looks like a kind of data format reflection mechanism.

> 2. Introduce new mandatory method for format drivers to determine the
> file format. Now GUI scenario will look like that:
> 
>  - select the file name;
>  - determine a format of that file;
>  - let the user choose open options, specific for that format;
>  - now proceed to GDALOpen(), capable to get options as per RFC 10.
> 
> Warning: between the second and the forth steps we have a race
> condition. But for this particular case it is not important.
> 
> Either way, for applications like Mapserver we should need to know the
> file format before writing the file name in its config file.

There seems to be yet another option or rather a variation of the 2nd
one. GUI applications may use OGRSFDriverRegistrar and its Open()
function to determine format of datasource passed in:

1. OGRSFDriverRegistrar::Open()
1.1. on success OGRSFDriver of returned OGRDataSource instance
2. Close the datasource
3. Use obtained driver to open the same datasource again but with custom
opening options passed

This is a kind of two-steps open action and is very similar to two steps
connection used in FDO:
- first step to answer what properties are required to open connection
- second step to pass required properties and establish connection

> The second approach is simpler to implement and also it is good to have
> separate format guessing method, it can be quite useful by itself. The
> problem still exist with formats that can't be easily identified though.

Right, it's similar to FDO's solution.

> Frank also suggested to pass encoded open options along with file name
> instead of having the separate parameter in Open() method. With this
> approach we will have different names to pass for format identification
> function and for GDALOpen(): pure file name for the former one and
> name+options for the last one. This will only work when we know the file
> format before opening the file, otherwise we just don't know what
> options are needed.

It sounds like usable approach but perhaps more complex to users.

> So the questions are: what approach looks better? Is there another
> possible solution?

I'd vote for your 2nd version.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net