Estimate and implementation plan

[simboss]

I would want to start with:

1. investigation and discussion between @giohappy ad @afabiani (take into account that we want to have QGIS talk to GeoNode)
2. estimate and implementation plan

Ideally I would want to have a simple REST Interface with Authentication rather than talking to Rabbit MQ.

[simboss]

@afabiani I see this is progress now.

Make sure whatever you come up with, you first align with @giohappy

[afabiani]

So far I did some tests on GeoNode side here. Currently those are my findings:

Exposing the updatelayers management command as an async task with Flower

The idea here is to create a celery task interface around the management command. GeoNode has several of those already available for a plenty of the internal management commands already. Creating such a task is very straight and won't take time.

How the task can be invoked then? There are several options here. The easiest is to use an utility called Flower which exposes an generic api around the Celery tasks. Here the API reference. You may notice that a task can be invoked both synchronously and asynchronously.

cons:

• The utility is not updated since a long time and it does not support Celery > 4.4.7. Nevertheless it works with GeoNode, even downgrading Celery, I already tested it.
• The only auth supported is basic auth with a single user. It currently does not support any integration with Django. Eventually there will be some work to do to wrap the auth here somehow, which might take time.

Estimated points: 2

Creating a rest interface

Not a bit issue either. Wrapping the command around a REST interface is not a big deal. We will need to better define such interface in order to handle the asynchronous invocation and retrieve somehow the responses from the command output.

For sure this is much work to do but not a complex task to achieve.

cons:

• GeoNode 3.1 (aka the current 3.x branch) does not have yet a good integration with the Django restframework. We can use it anyway, but it would be better to move to the new API V2 branch IMHO. That means that we will need to release ASAP 3.1 and push to merge on master the rest_api_apps branch.
• It would be good, eventually, to define a common way to expose GeoNode management commands through the REST apis, in order to avoid having single pieces of code to maintain.

Estimated points: 4

That said, we still need to coordinate with @giohappy in order to understand what we can do from QGis, even though I do not envisage hard blockers.