Ok thanks Ale. I'll focus on separating metadata handler and repository handler this week.
Cheers On Mon, Aug 1, 2016 at 10:24 AM, Alessandro Pasotti <apaso...@gmail.com> wrote: > On Mon, Aug 1, 2016 at 10:17 AM, Akbar Gumbira <akbargumb...@gmail.com> > wrote: > >> Hi Ale >> >> >>> Thanks for your report Akbar! >>> >> >> >>> I'm sorry if you've not taken into account my repeated calls to keep >>> authentication and proxy support in the primary goals. As I explained you >>> this is very important for some companies and organizations that needs >>> authenticated endpoints in their networks. >>> >> >> >>> If this plugin will not use this feature, the a.m. organization will not >>> be able to use it (and they will not invest any time or resources in its >>> maintainance or future development), they will just build their own sharing >>> solution. >>> >> >> >>> For this reason I've been pushing since the very beginning to use >>> QgsNetworkAccessManager for all network calls, in order to be able to use >>> QGIS proxy settings and authentication plugins. >> >> >> Agreed. In the network class, I used QgsNetworkAccessManager. The tricky >> part is the Dulwich's porcelain used to interact with git repositories. For >> this, I think we need to do it manually through git configuration to use >> proxy. >> > > > In this case we will loose authentication, but I guess it's not a great > issue: I don't think that git will be the preferred sharing protocol in > case of authenticated repos. > > > >> >> The algorithm could be: >>> # Browsing: >>> - for each the repo url: >>> - if it does not point to a metadata.ini file >>> - get the metadata address from the URL >>> - if we have an handler to retrieve the metadata.ini >>> - retrieve the metadata.ini >>> - else >>> - error >>> #Installing >>> - if the metadata does not contain a download URL for the collection >>> - build the collection download URL from the repo URL and protocol >>> and collection name >>> - if we have an handler to retrieve the collection >>> - download and install >>> - else >>> - error >> >> >> I was thinking to separate between Metadata Handler and Repository >> Handler as they don't have any correlation. For example, the metadata could >> be in an ftp and the repository could be in git. Doing if else (treating >> the only one git case: that the repository URL is a git repository and >> building a metadata URL from that URL is not that worth it). So when users >> add a repository, they add the metadata url. What do you think? >> >> > > It looks good to me, browsing metadata and installing a collection are two > separate steps (in time and scope) and it's worth splitting the URLs into > different protocol, if needed. > > Of course, for most repos, the handler and protocol will just be the same > for both operations. > > In general, I feels that this is a better approach also in the sense that > "explicit is better than implicit", we provide explicit URIs instead of > delegate guessing them to the software layer. > > Cheers > > -- > Alessandro Pasotti > w3: www.itopen.it > -- *-------------------* *Akbar Gumbira * *www.akbargumbira.com <http://www.akbargumbira.com>*
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer