Hi Borys, I just had a look at the plugin manager. Big thumbs up, this is good stuff!!
To your question: version 2 sounds reasonable to me as well. We can easily control the future parameters and append the qgis version always. Am I correct, that in the future, there is no (easy) way of installing an older version of a plugin? If yes, I'm not really a fan. If the plugin maintainer releases a buggy version, there is no way to revert to an old working version until the maintainer releases a bugfixed version. All in all, what are we talking about in terms of size? With a compression enabled HTTP connection, I don't expect the plugin xml to be too large to pass through any internet connection in a timely manner. Also, this request can easily happen asynchronously, so we don't even have to interrupt the UI. Best Matthias On Don 06 Jun 2013 13:57:28 CEST, Borys Jurgiel wrote: > With the new SIP API, we should find the best way to publish plugins for > various QGIS versions in one repository. It's no problem in small > repositories, where all multiple versions may exist side by side, because the > plugin installer (both: old and new) can filter the best availale version. But > the new central repository contains hundrets plugin versions, so for > performance reasons it only exposes the most recent version of each plugin in > the xml. If QGIS version is explicitly pass in the url (e.g. > http://blahblahblah.xml?qgis=1.9), the repository returns the most recent > *compatible* version. Otherwise - just the most recent. The new installer > includes current QGIS version to the URL, old one doesn't. So if there is an > old plugin version for QGIS 1.x, and a newer for QGIS 2.0+ , Qgis 1.8 won't > show it at all - because the repository will only return the latter, what will > incompatible. > > There is a few solutions I see: > > 0. Don't change anything, just say to plugin maintainers to make all existing > plugins compatible with both API. IMHO unacceptable solution; it was possible > for small API improvements during 1.x API, but forcing people to maintain > completely old API in complex plugins can only discourage them from further > maintaining. > > 1. Release an update for the the old plugin_installer, with the current > version added to the url. Fast and easy, however I see some downsides: > - Generally I'm not very keen to mess user's dicertory with core plugin > updates unless it's really justified. > - Either 1.8 packages will be updated too or it will require immediate > plugin_manager upgrade right after installation. > - Unless the plugin_manager is upgraded, many plugins dissapear. Looks like a > nasty and surprising regression during using the stable 1.8. This is probably > disqualifying. > > 2. Change the new repository policy: let it returns plugins for QGIS 1.8 when > called without the ?qgis= url parameter. This means: the ?qgis= parameter is > required, and the lack of it is a depreciated exception, only designed for > QGIS 1.8. With this reservation it looks reasonable for me. Please note the > new pyplugin_installer (it's a part of the manager working usually under the > hood) adds this ?qgis=$CURRENT_VERSION parameter anyway. > > 3. Like 2, but return the full list of plugins when called without the > parameter. Advantage: more clear than 2. Disadvantage: more server load and > longer (maybe much longer?) repository fetching in QGIS 1.8 > > > I vote for the solution 2. > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
