[gdal-dev] vsis3/vsicurl allowed-extensions per path?

[Robert Coup]

Hi Even,

On Wed, 10 Oct 2018 at 15:42, Even Rouault <even.rouault at spatialys.com>
wrote:

> > eg. gdal.Open("/vsis3?ext=.tif/mybucket/mypath/my.tif", ...)
>
> Hum, we should treat the path to the object as a real URL argument then,
> so something like
>
> /vsis3?ext=.tif&object=mybucket/path/to/my.tif
>

If we're splitting it out, should bucket and the object key (S3 uses the
term "key" in it's documentation) be separate parameters?

ie.
/vsis3?bucket=mybucket&key=path/to/my.tif&ext=.tif
/vsis3?bucket=mybucket&key=path/to/my.tif&ext=.tif&ext=.tif.aux.xml
/vsis3?bucket=mybucket&key=path/to/my.tif&ext


> with the path value being URL-encoded if needed (like the similar syntax
> added in 2.3 for /vsicurl/:
>
> https://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl
> )
>
>
Sure.

Are there other options that would be useful per-dataset?
GDAL_READDIR_ON_OPEN is exposed as ?list_dir=yes|no for vsicurl, maybe that
should be added here too?


> >
> > Another alternative would be to have it as an Open Option to pass to
> > gdal.OpenEx(), though they seem designed for driver-specific options
> rather
> > than access-method.
>
> That one would be nice, but tricky. Basically, the config option must be
> set at the time a
> Open() or Stat() action is done, but GDALOpen() has no control on when the
> driver will
> performs such actions. One could presume they will be done by the open
> code of the driver, but
> who knows if a driver might not do deferred access, after the Open()
> method has been
> completed.


Makes sense.

Cheers,

Rob :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20181010/1901e4d8/attachment.html>