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

[Victor Olaya]

>From the point of view of SEXTANTE, I like the idea of having a
library that other developers can use to get access to the sharing
platform. Just make sure that the library is well-documented and to
provide an example case for a given resource, so other people can use
that as a model to implement the same functionality from their own
resources.

In the case of SEXTANTE, models, script and R scripts look like the
most interesting ones to share, and if the library is ready and
working fine, that could be directly implemented in the SEXTANTE
toolbox, so it can be populateed with resources from the sharing
platform.

Feel free to ask me in case you want more information about this, so
as to have a good overview of what we users of your library would like
to have to make our work easier.

Keep up the good work!

Cheers
Victor


2013/7/31 Borys Jurgiel <lists at borysjurgiel.pl>:
> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer