<div dir="ltr">Hi Frank, <div><br></div><div>I was one of the original people who argued against the "array of strings" approach...<br><div class="gmail_extra"><br><div class="gmail_quote">On 27 August 2015 at 02:26, Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I clearly should have been commenting sooner.<br></blockquote><div><br></div><div>Several months ago :p</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am concerned that having messy structures of options for each<br>
program is going to complicate maintaining the actually commandline<br>
programs, and that it will still be a fragile and complicated point of<br>
entry as commandline arguments evolve over time.<br></blockquote><div><br></div><div>The commandline tools eventually become string-parsing and wrapping of the corresponding library tool - I'm not sure that makes it fragile & complicated? Means that the library-ified apps are <i>at least as</i> flexible/expressive/powerful as the command-line tools.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd prefer if the approach had just been to embed the main()'s in a<br>
library and to still pass the exact same vector of arguments (in the<br>
char **argv format) to these functions instead of shelling out a<br>
program.<br></blockquote><div><br></div><div>That kinda defeats the whole point - a huge array of complex string-ified arguments is what we're all doing at the moment, wrapped in an subprocess call. Some options take multiple arguments in multiple strings, others take multiple arguments in single strings, it's massively confusing. And we all have big pipelines of chained gdalwarp/gdal_translate/etc code...</div><div><br></div><div>What we were striving for was to make it distinctly <i>better</i>:</div><div><ul><li>progress/logging/error handling</li><li>options that accept geometries or SRS or in-memory datasets without having to re-serialize them and/or utilise tempfiles</li><li>easily applying the same operations over multiple datasets</li><li>configuration option defaults</li></ul></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I would love to be able to replace many places where I shell out to<br>
run gdal command line programs with a library call with essentially<br>
the same arguments.<br></blockquote><div><br></div><div>Sure, so it should be straightforward to do that <i>as well</i>, though besides in-memory data (as you mention) you're getting very little benefit.</div><div><br></div><div>Rob :)</div></div><div class="gmail_signature"></div>
</div></div></div>