<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Rob,</p>
<blockquote type="cite"
cite="mid:CAFLLRpJT1kx1frrYUfWeyQubY9nX_ouYsZEegXhJVLtd4ANw8A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote"><br>
<div>Is it worth reserving space for a future Git or
Github-cli style plugin mechanism where third party tools
can extend the `gdal` CLI? eg: `gdal raster from-contours`</div>
<div>
<ul>
<li>`git foo` simply looks for internal code first, then
executes `git-foo` if it's present, then expands any
configured command aliases<br>
</li>
<li>Github cli has an explicit extension install/packaging
mechanism: <a
href="https://docs.github.com/en/github-cli/github-cli/creating-github-cli-extensions"
moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.github.com/en/github-cli/github-cli/creating-github-cli-extensions</a><br>
</li>
</ul>
</div>
</div>
</div>
</blockquote>
<p>I would let that aside for now (trying to limit as much as
possible the scope of the current RFC to avoid it going out of
control). That's something that should be relatively easy to add
if someone needed that. But actually you can already extend the
"gdal" utility, for commands a the top level, if you provide a
shared library in the gdalplugins directory and that it registers
an algorithm the same way built-in algorithms do. The bonus point
doing that way is that potential GUI built on top of gdal that
would use "gdal --json-usage" (or the equivalent C/C++ API) would
autodiscover such extension with its supported options.</p>
<p>Even<br>
</p>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.</pre>
</body>
</html>