I'm sorry I didn't mention it earlier. Well, now I'd start from writting down all the needed metadata tags (for plugins they are in the file I mentioned; Victor, could you prepare such list for SEXTANTE?) and all needed API calls. I believe it may lead to a decision of making qgs classes for data structures, like I mentioned. Those structures can be still populated with data by the serverside-filtering API, to not invest too much GSoC time into refactoring. A new API can be added in version 2 and the old one can be depreciated (or not) in a version 3... I must say I don't have much experience with similar solutions existing around, so for me your work on styles is still a kind of prototypying, and I expect many ideas may change.
Anyway, my next task should be a real versioning for plugins, in order to allow downloading (and locking) any previous version of a non working plugin. As I'd like to avoid downloading all the thousands of plugins x versions in each request for local filtering, we'll probably have to add more requests to the API. Most likely, there will be an aditional metadata tag "alternate_versions" included to the main big request, and also another requests for details of the chosen version. I'll think about it for Brighton. As you see there is still a lot of details to be precised, so don't be disappointed if you find your present work more a prototype than the final long- term stage :-) Borys Dnia czwartek, 1 sierpnia 2013 o 17:47:02 [email protected] napisaĆ(a): > 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. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
