Re: [gdal-dev] vsicurl configuration design decisions

2017-10-16 Thread Sean Gillies
Done: https://trac.osgeo.org/gdal/ticket/7095. On Fri, Oct 13, 2017 at 4:29 PM, Even Rouault wrote: > Sean, > > > I'd like to point out that very often URLs in a query string do not need > to > > be encoded. Both the Python (see my earlier example) and Node standard > > parsers will handle the s

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-13 Thread Even Rouault
Sean, > I'd like to point out that very often URLs in a query string do not need to > be encoded. Both the Python (see my earlier example) and Node standard > parsers will handle the string > While researching that issue, and from my pat memories, I found that there is a bit of confusion around

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-13 Thread Sean Gillies
Even, Craig, On Thu, Oct 12, 2017 at 4:15 PM, Even Rouault wrote: > Craig, > > > > > True, but that does eliminate ambiguity in the URL, and does so in a > > > well-known way. > I'd like to point out that very often URLs in a query string do not need to be encoded. Both the Python (see my earli

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-12 Thread Even Rouault
Craig, > True, but that does eliminate ambiguity in the URL, and does so in a > well-known way. > > Does the current scheme use any encoding? No > How would you escape text in > option values that might use `=` and `,` etc? Or are there guaranteed to be > no freeform-text options in these paths

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-12 Thread Craig de Stigter
Hi folks We're slightly invested in this because we use VSI paths reasonably heavily, though not so much for cloud services yet. > One downside is that you need to URLEncode the URL, which can make it > painful when composing it at hand. True, but that does eliminate ambiguity in the URL, and

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-12 Thread Even Rouault
Hi Sean, > Is the future of open and creation options? I don't understand your above sentence. > Do you imagine this extended > to, say, block size, compression, number of threads? An RFC that discussed > the scope of this and at what level of abstraction it is implemented at > might be warrante

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-12 Thread Sean Gillies
Hi Even, On Tue, Oct 10, 2017 at 4:02 AM, Even Rouault wrote: > Hi Sean, > > > > > > > > It's written in > > > http://gdal.org/gdal_virtual_file_systems.html#gdal_ > virtual_file_systems_vsi > > > curl > > > > Starting with GDAL 2.3, options can be passed in the filename with the > > > > > > fol

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-10 Thread Even Rouault
Hi Sean, > > It's written in > http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsi > curl > > Starting with GDAL 2.3, options can be passed in the filename with the > > following syntax: /vsicurl/option1=val1[,optionN=valN]*,url=http://... > > I'd like to discuss the de

Re: [gdal-dev] vsicurl configuration design decisions

2017-10-09 Thread Frank Warmerdam
Sean, The obvious answer is that interfaces that are organized around the dataset name do not make it easy to transport other parameters in a way that is specific to one dataset. While I worry a bit about complex dataset syntaxes I do think there is a power to embedding these options in the datas

[gdal-dev] vsicurl configuration design decisions

2017-10-09 Thread Sean Gillies
Hi all, It's written in http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl : > Starting with GDAL 2.3, options can be passed in the filename with the following syntax: /vsicurl/option1=val1[,optionN=valN]*,url=http://... I'd like to discuss the design decisions that