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

[aruntheguy at gmail.com]

Hello,

Thank you for the ideas. And Borys, your idea does make me question a
lot of things and the approach I have taken. As far as the symbols go,
I think I am on the right side with server side filtering. But when we
move towards more complicated stuff with votes, and versioning, it
does makes sense to have a local cache of meta-data to do the
filtering. I guess I will have to think more about this and figure out
the distinction and the way through it. Thank you for giving me the
other way to do.

On 8/1/13, Victor Olaya <volayaf at gmail.com> wrote:
> 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
>


-- 
Regards
Arunmozhi