[gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

[Robert Coup]

Hi Frank,

I was one of the original people who argued against the "array of strings"
approach...

On 27 August 2015 at 02:26, Frank Warmerdam <warmerdam at pobox.com> wrote:

> I clearly should have been commenting sooner.
>

Several months ago :p


>
> I am concerned that having messy structures of options for each
> program is going to complicate maintaining the actually commandline
> programs, and that it will still be a fragile and complicated point of
> entry as commandline arguments evolve over time.
>

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 *at least as*
flexible/expressive/powerful
as the command-line tools.


>
> I'd prefer if the approach had just been to embed the main()'s in a
> library and to still pass the exact same vector of arguments (in the
> char **argv format) to these functions instead of shelling out a
> program.
>

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...

What we were striving for was to make it distinctly *better*:

   - progress/logging/error handling
   - options that accept geometries or SRS or in-memory datasets without
   having to re-serialize them and/or utilise tempfiles
   - easily applying the same operations over multiple datasets
   - configuration option defaults



>
> I would love to be able to replace many places where I shell out to
> run gdal command line programs with a library call with essentially
> the same arguments.
>

Sure, so it should be straightforward to do that *as well*, though besides
in-memory data (as you mention) you're getting very little benefit.

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