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 <[email protected]> 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 <[email protected]>: >> Dnia środa, 31 lipca 2013 o 19:21:08 [email protected] 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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Regards Arunmozhi _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
