[GRASS-dev] [QGIS-Developer] External providers in QGIS

[Moritz Lennert]

On 08/02/18 13:43, Rashad Kanavath wrote:
> 
> 
> On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya <volayaf at gmail.com 
> <mailto:volayaf at gmail.com>> wrote:
> 
>         OTB's proposed solution was that plugin or provider algorithm if
>         activated can find otb installation. If not found, there is code
>         which will download and install otb packages and configure it
>         for users.
> 
> 
>     I still don't see why this cannot be done if OTB provider is a
>     separate plugin. Users can install a plugin with the provider, and
>     then that provider can have the logic to automatically download OTB,
>     install it, or do whatever is needed in case OTB is not found
>     already installed.
> 
>     I think is is good to educate our users a little bit. We are talking
>     about people that will be using complex algorithms for performing
>     advanced analysis. I guess we can expect that they can install a
>     plugin themselves and it is not a traumatic experience for them...
>     Looks like installing a separate plugin it's some sort of cruel
>     chinese torture...when it takes just 3 mouse clicks.
> 
>     I agree with Giovanni, there is no need to provide something that
>     has everything installed out-of the box. Also, take into account
>     that reading the files that contain the algorithm descriptions takes
>     time (plus, there might be some additional checks performed when
>     populating the toolbox). People not doing analysis should not have
>     to suffer that extra loading time...
> 
> 
> QGIS increases no of algorithms for a provider. It is simple as that. 
> OTB has less than 80 applications and coming to QGIS, it will be 100 or 
> 150. (no interest to count them in qgis)
>   And OTB was reading descriptor from xml which is going to be now csv 
> like others.
> Given all that info, I won't be surprised if it takes more time in 
> future because of new algorithms added to providers. If QGIS was reading 
> proper way or even open to accepting fixes.
> 
> The entire proposal/request to put back OTB was that decision was made 
> on OLD code. when the update code is there, it has less problems.
> Based on concerns raised by other developers no matter if you can fix 
> it, they can't be put back. This single point was fueling this and other 
> threads.
> Also discussion wasn't started with "why no providers are included?". It 
> was why some of them are removed even if there is an offer to help!
> 
> I don't care enough to continue this discussion about plugin or not plugin.
> 

Warning: I don't claim any knowledge of the actual QGIS provider code, 
but I'm afraid that this is the case for many external SW developers, so 
please bear with me and correct me where I'm wrong.

However, I do have the feeling that part of the debate is due to 
fuzzyness of the actual subject. AFAIU, there a different issues here, 
and only if we clarify what we are talking about exactly, and what the 
actual issues are, can we advance. So, here's my understanding:

1) the descriptor files of the different algorithms in external SW

It seems that at least from OTB and GRASS side, willingness has been 
signaled to take over the handling of those.

2) the code that allows to launch these algorithms from within QGIS

IIUC this is again subdivided into two parts:

- a generic class within QGIS code for creating a provider
- the specific external SW related instances of these classes

The first part is definitely part of QGIS core.

The current debate (again AFAIU) is mostly about the second part. And 
one question linked to this is how much of the handling can be done by 
the generic class code, and how much is SW-specific. IOW, would it be 
possible to have exactly the same format of descriptor files for all SW, 
and a generic API to interpret those, or are the idiosyncrasies of the 
different SW such that API and descriptor files will have to be SW 
specific ?

A second question is how much within the second part (the SW specific 
provider) depends on evolutions of QGIS code, i.e. when QGIS moves from 
one version to the next, will the code in this part have to change, or 
will it remain stable, and how much depends on evolutions in the 
external SW code. If changes in external SW happen more often than it 
seems to make sense to keep this part of the code away from QGIS core, 
but if changes in QGIS happen more often than the opposite would seem 
better.

Another issue is that current expertise on how to code these providers 
is within the QGIS development team. If you decide to put these 
providers into plugins, _and_ to no longer ensure the maintenance of 
these plugins, this would mean that the development teams of the 
external SW have to acquire the necessary knowledge. Looking at general 
scarcity of human power in all of the teams, I'm not sure this will 
happen easily.

Do I understand things correctly ?

Moritz