[Gdal-dev] Re: RFC 10

[Andrey Kiselev]

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.

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.

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.

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.

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.

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.

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

Best regards,
Andrey

-- 
Andrey V. Kiselev
ICQ# 26871517