[GRASS-dev] External providers in QGIS

[Rashad Kanavath]

Hello victor,

Do you see a possibility of a generic processing provider?. One that can
read descriptor files and run algorithms!.
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!.
Whichever toolbox want to be integrated into processing plugin can provide
and maintain descriptor files individually. No QGIS developers need to be
involved.
This way, external toolboxes' team or qgis does not need to maintain/fix
qgis-<TOOLBOX>-provider-plugin.

search -> download -> install plugin will be changed to configure providers
install location.
If needed QGIS can control list of available providers (just names).

External tools' dev team needs to know something such as spec of descriptor
files, how to mention name of executable etc.
They don't need to know stuff like how qgis run a processing algorithm, and
things working of modeler, running with other algorithms.

Anyway, this is just an idea and don't know what will be technically
challenging issues?

The other way of putting processing plugin into core and providers
classified as external plugins can avoid maintenance on qgis.
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
Putting all stuff in qgis tree and taking no responsibility of providers
isn't good either.

This way, each team takes part and result in better collaboration and
contribution.
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.


On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <volayaf at gmail.com> wrote:

> 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.
>
> 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?
>
> 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.
>
> Cheers
>
>
>
> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
>
>> Hi all,
>> following the discussion on qgis-dev ML:
>> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
>> it has been proposed to remove all external providers (namely OTB,
>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>> remain as QGIS cannot be built without). This raised a number of
>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>> release, and to open a wider discussions about this, involving all the
>> interested parties, to find an optimal solution.
>> If volunteers outside QGIS core team, ideally from the respective
>> backends, could take the maintenance of these providers, not much would
>> change for the end user. If not, this will mean effectively missing
>> hundreds of algs from QGIS.
>> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
>> as maintainer.
>> QGIS.ORG will seek to support any decision made with funding where
>> possible.
>> Looking forward for your feedback.
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
>>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180207/f5f51c4b/attachment-0001.html>