[Qgis-developer] [SoC] Resource Sharing in QGIS - Weekly Report #6

[Borys Jurgiel]

Dnia środa, 31 lipca 2013 o 19:21:08 aruntheguy at gmail.com napisał(a):
> Hello,
> 
> Sorry for the late reply. With respect to the types of resources, I had
> symbols, symbology style sheets, plugins, script runner scripts, sextante
> models, and if possible print composer templates. But the basic idea is not
> to create a GUI for all of these or change the existing ones like the
> plugins downloader, that is already present. My idea is to create the
> remote infrastructure (server - qgis-django) with the required API and
> write the basic backend library for the Quantum-GIS desktop application.
> Then the desktop application API can be used at respective places, wherever
> required.

Sure. I mentioned the GUI issue,as I find it probably the most divergent part. 
All the rest (API for up/downloading, voting etc, qgs classes for storing 
metadata and handling communication, and the django part) could be probably 
easily unified... However look two paragraphs further.

> When I wrote the proposal, initially I had the idea to write a single
> plugin, perhaps in Python to show-case the idea. But presently I think
> writing the backend code in the "core" library would be more helpful than a
> single plugin for a particular resource. Basic working is downloading ->
> validating -> initiating integration. This is common to any resource we
> might share.

Exactly. 

> The present code with the QgsSymbolResource class in my gsoc13 branch is an
> example of the above mentioned methodology with GUI integration done in the
> Symbol Import Dialog.

So you used server-side filtering. My approach is different. First download 
metadata of all available and installed plugins to a metadata registry, then 
process it (filter, sort etc) locally. The metadata registry is just a nested 
QMap: 

QMap< QString plugin_id, QMap< QString property, QString value > >

Did you considered such approach? And if so, what downsides you see? I'm 
afraid for plugins it's the only solution, because of metadata complexity [1] 
and the need of finding updates at startup.

For styles, it looks like an overkill at this stage, however, if you'd like to 
implement filtering/sorting by votes or versioning/updating (like in plugins) 
in the future, I encourage you to consider refactoring the idea unless it's 
too late :-)

Instead of simple QMap of QMaps, there could be also some dedicated classes:

QgsAbstractMetadataRegistry ( containing a map of QgsAbstractMetadata )
QgsPluginMetadataRegistry ( containing a map of QgsPluginMetadata)
QgsSymbolMetadataRegistry ( containing a map of QgsSymbolMetadata)
etc. 

The QgsAbstractMetadataRegistry class could contain methods for fetching, 
downloading, uploading, voting etc. 

If you prefer to stay with your approach, probably the currently implemented 
core part of the installer has to remain separated, however, 
auhentication/upload/voting API probably can be shared. I'm not very familiar 
with the existing repository django app though.

I hope I didn't drive you mad with this idea of refactoring ;-))

Regards,
B.

[1]
https://github.com/qgis/Quantum-GIS/blob/master/src/app/pluginmanager/README