<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 1, 2016 at 10:17 AM, Akbar Gumbira <span dir="ltr"><<a href="mailto:akbargumbira@gmail.com" target="_blank">akbargumbira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Ale</div><span class=""><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">Thanks for your report Akbar!<br></blockquote><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">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.<br></blockquote><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">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.<br></blockquote><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">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.</blockquote><div><br></div></span><div>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. </div></div></blockquote><div><br></div><div><br>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div><br></div><div><div style="font-size:12.8px"><div><div><div><div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The algorithm could be:<br># Browsing:<br>- for each the repo url:<br> - if it does not point to a metadata.ini file<br> - get the metadata address from the URL<br> - if we have an handler to retrieve the metadata.ini<br> - retrieve the metadata.ini<br> - else<br> - error<br>#Installing<br>- if the metadata does not contain a download URL for the collection<br> - build the collection download URL from the repo URL and protocol and collection name<br>- if we have an handler to retrieve the collection<br> - download and install<br>- else<br><span style="font-size:12.8px"> - error</span></blockquote></div></div></div></div></div></div></div></div><div><br></div></span><div>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?</div><br clear="all"></div></blockquote></div><br><br></div><div class="gmail_extra">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. <br><br></div><div class="gmail_extra">Of course, for most repos, the handler and protocol will just be the same for both operations.<br><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></div>