[QGIS-Developer] External providers in QGIS

[Victor Olaya]

I dont think that it is possible to make it more generic. It's not only
descriptors with only outputs and inputs. Each backend app has its own
logic. GRASS needs outputs to be converted to its own format. SAGA accepts
only SHP for vector layers and generates its own SDAT format for raster
outputs. Parameters are also not passed in the same way to all apps. SAGA
has extent parameters splitted in 4 params with bbox coordinates. Each
provider has a different way of indicating a boolean value in the console
call. In short, the logic must be there somehow, specific for the provider,

What is the difference between maintaining a set of descriptor files (as
you propose) and a set of descriptor files + a class extending
GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
easier to have a solid provider class for OTB and then do not ever change
it (assuming OTB syntax will never change), than having a generic provider,
which looks rather unfeasible.

As you say, there is the risk for dead code. In that case, i think it is
much better to have the provider outside of QGIS core, as a plugin. There
are dozens of dead plugins, and that is not nice, but it's kinda
acceptable. Having dead code in QGIS it's a much bigger issue, and we must
avoid that.

Cheers



2018-02-07 14:41 GMT+01:00 Rashad Kanavath <mohammedrashadkm at gmail.com>:

> 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-Januar
>>> y/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/qgis-developer/attachments/20180207/83b597c1/attachment.html>