[Gdal-dev] Re: RFC 10

[Mateusz Loskot]

Andrey Kiselev wrote:
> On Mon, Nov 12, 2007 at 03:36:51PM -0500, Frank Warmerdam wrote:
>>> 
>>> 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.
>> Note that the approach of encoding driver specific options into the
>> name is already widely used for OGR - mainly for the various RDBMS
>> drivers.
> 
> Yes, but it is not standartized and weak in many ways. Also it is clear
> that we need open options, for example, PG driver uses PGSQL_OGR_FID
> variable for some purpose, that is certainly a thing that should be
> configured as an per-datasource parameter.

Perhaps we could you JSON syntax or something similar for GDAL/OGR options:

{
option1 : value,
option2 : value
}

and pass it as a single string to the open function, together with
native connection string:

char const* pszName =
"PG:\'dbname=test\'{option1=value,option2=value}";

where the part enclosed with {} is considered as options list.

char const* pszName =
"{option1=value,option2=value}ODBC:userid/password at dsn";

as above, the part enclosed with {} consists of options list.

Perhaps it would be required to use double-braces "{{option1=value}}

However, all these conventions require extra actions from a
user to encode the connection string.

>> I'm not clear on why RFC 10 couldn't be altered to provide a standard
>> mechanism to encode parameters into the datasource name and go from
>> there.  The issue of applications which don't know the format apriori
>> is not new.
> 
> If the identification function will be added to OGR we will have two
> forms of datasource naming. Identification function will accept a pure
> dataset name, because we don't know what options are acceptable at this
> stage, and we don't need them here anyway. Open function should get
> datasource name AND open options: here we know what parameters we need
> and already asked our user to set them. Note, that username/password
> thing of mentioned PG driver is a part of datasource name and not an
> option: we need these things to check database existence and establish
> connection.  Though PGSQL_OGR_FID is an optional parameter and it is
> only required when the actual data reading starts.

I agree with Andrey's reasoning.

> So the programmer will need to use the following code to open datasource
> with open options:
> 
>  ds_name = "datasource_name";
>  format = Identify(ds_name);
>  if (format == "OUR_FORMAT") {
>   options = AskUserForOptions();
>   some_kind_of_new_name = CombineAndQuoteStrings(ds_name, options);
>   ds = OGROpen(some_kind_of_new_name);
>  }
> 
> instead of
> 
>  ds_name = "datasource_name";
>  format = Identify(ds_name);
>  if (format == "OUR_FORMAT") {
>   options = AskUserForOptions();
>   ds = OGROpen(ds_name, options);
>  }
> 
> I think it is just clearer and simpler for developer.

I agree.
Also, the second version is compatible with convention of passing
creation options [1], so it's more intuitive for GDAL/OGR users.

[1] options passed as a list to functions
OGRSFDriver::CreateDataSource() and GDALDriver::Create()

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