<div dir="ltr">Hello victor,<div><br></div><div>Do you see a possibility of a generic processing provider?. One that can read descriptor files and run algorithms!.</div><div>I see processing as a single plugin (included in QGIS or not). And if it can avoid need to have sub-plugin managed by all those other development team. That's even better!.</div><div>Whichever toolbox want to be integrated into processing plugin can provide and maintain descriptor files individually. No QGIS developers need to be involved.</div><div>This way, external toolboxes' team or qgis does not need to maintain/fix qgis-<TOOLBOX>-provider-plugin.  </div><div><br></div><div>search -> download -> install plugin will be changed to configure providers install location.</div><div>If needed QGIS can control list of available providers (just names). <br></div><div><br></div><div>External tools' dev team needs to know something such as spec of descriptor files, how to mention name of executable etc. <br></div><div>They don't need to know stuff like how qgis run a processing algorithm, and things working of modeler, running with other algorithms.</div><div><br></div><div><div>Anyway, this is just an idea and don't know what will be technically challenging issues?</div></div><div><br></div><div>The other way of putting processing plugin into core and providers classified as external plugins can avoid maintenance on qgis.  </div><div>But this "strategy" can result in dead code and users complaining on both projects. Because, at some developers cannot manage project release + a plugin for qgis, another plugin for matlab or whatever</div><div>Putting all stuff in qgis tree and taking no responsibility of providers isn't good either. </div><div><br></div><div>This way, each team takes part and result in better collaboration and contribution.<br></div><div>As time goes, generic descriptor provider gets better and stronger.  Toolboxes are free to add, remove, modify their applications and users from both community benefit best of both worlds.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <span dir="ltr"><<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I dont see the advantage in having providers in core. And if there is an advantage, it's clearly not in how easy it is going to be to maintain the plugin. If the people responsible of a given backend (like OTB) are going to maintain it (which makes sense), why putting it in core where they don't have write access? Better in a separate repo. Also, they can release whenever there are changes, without having to wait for a new release. That way, the plugin will always be in sync with new releases of the backend app.<div><br></div><div>If we put them in core...why putting only this big ones (which in some cases require installing external apps manually by the user), and not put other plugins that exist and contain Processing providers? </div><div><br></div><div>I thought the idea was to not have core plugins and avoid them if possible. I don't see why we have to treat plugins that have Processing provider in a different way. Specially considering how easy it is to install a plugin in QGIS.</div><div><br></div><div>Cheers</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-02-06 18:57 GMT+01:00 Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
following the discussion on qgis-dev ML:<br>
<a href="https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/piperm<wbr>ail/qgis-developer/2018-Januar<wbr>y/051701.html</a><br>
it has been proposed to remove all external providers (namely OTB,<br>
already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will<br>
remain as QGIS cannot be built without). This raised a number of<br>
concerns, so PSC decided not to rush removing them from the upcoming 3.0<br>
release, and to open a wider discussions about this, involving all the<br>
interested parties, to find an optimal solution.<br>
If volunteers outside QGIS core team, ideally from the respective<br>
backends, could take the maintenance of these providers, not much would<br>
change for the end user. If not, this will mean effectively missing<br>
hundreds of algs from QGIS.<br>
I personally propose to reinstate the OTB plugin with Rashad (from OTB)<br>
as maintainer.<br>
<a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a> will seek to support any decision made with funding where possible.<br>
Looking forward for your feedback.<br>
All the best.<br>
<span class="m_6321785772542877111HOEnZb"><font color="#888888">--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/trainin<wbr>g.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=qgis<wbr>,arcgis</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div>