<div dir="ltr">Hi all,<div><br></div><div>It's written in  <a href="http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl">http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl</a>:</div><div><br><div>> Starting with GDAL 2.3, options can be passed in the filename with the 
following syntax: /vsicurl/option1=val1[,optionN=valN]*,url=<a href="http://..">http://..</a>.<br></div><div><br></div><div>I'd like to discuss the design decisions that are being made here before this gets out into the world.</div><div><br></div><div>I'm uncomfortable with the way configuration is spread between environment variables, config options that surface in the API, and also in identifiers. I don't think it's a great idea to that expand the amount of configuration in dataset identifiers. It's redundant, the syntax is complicated, and it dilutes the network effects of reusing identifiers in our applications.</div><div><br></div><div>Are there specific advantages to this </div><div><br></div>  ogrinfo -so /vsicurl/max_retry=10,url=<a href="https://example.com/poly.shp">https://example.com/poly.shp</a><div><br></div><div>that we can't also have with a curl-style</div><div><br></div><div>  ogrinfo -so --max-retry=10 /vsicurl/<a href="https://example.com/poly.shp">https://example.com/poly.shp</a><br></div><div><br></div><div>or, better yet, in my opinion</div><div><br></div><div><div>  ogrinfo -so --max-retry=10 <a href="https://example.com/poly.shp">https://example.com/poly.shp</a><br></div></div><div><br></div><div>on the command line?</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>