Re: [gdal-dev] Resquest for comments (RFC 36)

[Ivan Lucena]

Frank,

Sorry for the confusion. Please disregard my last message. I didn't had the time to edit it properly.

But I am happy to see that the discussion has brought some interesting ideas and some important concerns.

That is what I think we should do:

- Keep backward compatibility. Simple files names and drivers specific entries should works as usual;
- The initial approach, "drivername:" is misleading and problematic;
- We should use an unambiguous token to express exactly that a driver has been chosen.

In my option the "driver=" is the best approach because:

- It is simple enough to be used in command line, if needed (what is rarely the case);
- It works well with entries like "table=" or "user=";
- It doesn't create problems with driver that consume prefixes that are not real drivers names.

> The "@" prefix is the clue to kick into the special logic.  We would
> likely want to avoid it if the file "@driver=gtiff,landsat1.tif" actually
> existed in the filesystem.

Please note in the proposed code that If the file exist ("oOpenInfo.bStatOK == false") there is no need to check for anything else. Existing file will always be handle by the driver probing. IMHO I would rather not have the "@". The possibility of having a file by the name of "driver=something" is basically the same as "@driver=something".

Except by the "@", I agree with what you and Even discussed as a proposed format:

> @[driver=drivername,]option1=value1,options2=value2,filename

I would guess that the list of "option=value" and "filename" would be parsed by GDALOpenInfo constructor, like in:

  GDALOpenInfo oOpenInfoClone( "option1=value1,options2=value2,filename", eAccess );

That should work well in either strategy, driver probing or open-by-drivername. I think.

My best regards,

Ivan

>  -------Original Message-------
>  From: Frank Warmerdam <warmerdam at pobox.com>
>  To: Even Rouault <even.rouault at mines-paris.org>
>  Cc: gdal-dev at lists.osgeo.org, Ivan Lucena <ivan.lucena at pmldnet.com>
>  Subject: Re: [gdal-dev] Resquest for comments (RFC 36)
>  Sent: Oct 04 '11 13:52
>  
>  On Tue, Oct 4, 2011 at 11:42 AM, Even Rouault
>  <even.rouault at mines-paris.org> wrote:
>  > That's exactly my understanding of what the latest patch
>  > http://trac.osgeo.org/gdal/attachment/ticket/3043/open_by_drivername_v3.patch
>  > does.
>  
>  Even,
>  
>  Good, but I didn't understand what Ivan was suggesting/proposing.
>  
>  >> The main advantage of the @ approach is that it is intended to be
>  >> easier to specify multiple open options.
>  >
>  > Even if it is not in the scope of current RFC, do you have an idea of what the
>  > syntax would be for open options so as we can pick up something that could be
>  > later extended ?
>  >
>  > Something like :
>  >
>  > @[driver=drivername,]option1=value1,options2=value2,filename ?
>  
>  This was my rough intention with, hopefully, well defined quoting or
>  escaping rules to take into account the case where the regular filename
>  contains commas.  One of the thing that held me back from pushing
>  this was coming up with good rules on quoting/escaping.  The use of
>  quotes in subdataset names in stuff like the HDF driver is a great headache.
>  In the gdalinfo report on a HDF driver we try to report the subdataset names
>  with clear quoting, but if folks cut and paste that into a shell the quotes
>  get eaten by the shell which makes it very hard for users to know what
>  they need to do unless they are quite shell-savvy.  I'd like to avoid that
>  if possible.
>  
>  
>  >> Particularly on the OGR side
>  >> there has long been a desire to control how some DB opens are done
>  >> with extra open options but now the only way we can provide these is
>  >> via config options.
>  >
>  > Actually on OGR side, apart from the configuration options, you also have the
>  > notion of connection strings, like for the PG driver, to provide the driver
>  > name, database name, host, port, etc etc...
>  
>  Yes, my intention was to regularize how connection strings are done.
>  So if applied to the postgres driver we would have stuff like:
>  
>    @driver=pg,host=localhost,password=tiger,dbname=ottawa
>  
>  What I don't like now is that the connection string parsing,
>  quoting, etc is handled differently in the different DB drivers.
>  
>  Best regards,
>  --
>  ---------------------------------------+--------------------------------------
>  I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>  light and sound - activate the windows | http://pobox.com/~warmerdam
>  and watch the world go round - Rush    | Geospatial Software Developer
>