<div dir="ltr"><div>Hi Ale</div><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><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><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><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><div><br></div><div> Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 9:29 AM, Alessandro Pasotti <span dir="ltr"><<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@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><div><div><div><div><div><div><span class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 30, 2016 at 10:39 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><b>What did you get done this week?</b><div><ul><li><b>Implemented style resource handler</b></li></ul></div><blockquote style="margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-color;padding:0px"><div><div>User can now also put style (qml file) in the collection.</div></div></blockquote><div><ul><li><b>Fixed issues on windows</b></li></ul></div><blockquote style="margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-color;padding:0px"><div><div>It should be testable now on Windows. There is an issue on windows while downloading the repository using ssh. I haven't prevented that (e.g restricting to use https only when adding a repository in the settings - but I guess it's easier to do this rather than checking if the host has ssh installed)</div></div></blockquote><div><ul><li><b>Wrote some documentation</b> (<a href="http://www.akbargumbira.com/qgis_resources_sharing/" style="font-size:12.8px" target="_blank">http://www.akbargumbira.com/qgis_resources_sharing/</a>)</li></ul><ul><li><b>Implemented file system handler</b></li></ul></div><blockquote style="margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-color;padding:0px"><div>User can now use repository in the local file system. The URI should have this format: file://<path to the repo root>. On Windows it looks something like this <b>file://C:/home/akbar/repo. </b>On linux: <b>file:///home/akbar/repo</b>.</div><div>This could be useful for:</div></blockquote><div><ul><ul><li>Testing if the repository works fine before pushing to github/bitbucket (user can try to add a repo in the stting pointing to the filesystem)</li><li>In case someone wants to use private repo, they can pull it to their local machine, and just use that local clone</li><li>Sharing the repository on the network</li></ul></ul><div><b>What do you plan on doing next week?</b></div><div><ul><li>Documentation and unittests</li><li>Using QGIS authentication system in the settings tab when adding a repository (this would be easy in the case of fetching metadata from the repository, but might be tricky for cloning/pulling repository itself)</li><li>Ale and I had a talk on friday and zip repository handler might be useful for users (i.e the author makes a zip of the repository on publish it somewhere online). With the current implementation of repository handler (the metadata must be inside the repository itself), this might take some effort to implement. We don't want to download the whole zip just to get the metadata file. Ale's idea is to separate the metadata and in the metadata, additional things has to be defined: the protocol (e.g git, file system handler, or ftp, scp maybe in the future), and the location of the repository itself. I am a bit hesitant with this idea from the beginning (Ale already suggested this before :)) as I think the metadata and the repository must be in the same directory. It's nice to not have the protocol and the location of the repository statically defined. As I mentioned earlier with file system handler, user now can clone private repository in github/bitbucket and use file system handler. There's no need to change the metadata of the repository before using it (this is needed if we want to take Ale's idea). Anyway, I'll think about this over the weekend and see if I could implement this on time and still have time to polish things up.</li></ul><div><br></div></div><div><b>Are you blocked on anything?</b></div><div>No, just need to have more opinions on the situation I mentioned above.</div><div><br></div><div>Have a nice weekend. Cheers!</div><span><font color="#888888">-- </font></span><br></div></div></blockquote></div><br><br></div></span><div class="gmail_extra">Thanks for your report Akbar!<br><br></div><div class="gmail_extra">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><br></div><div class="gmail_extra">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></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">For the zip/tar file handler (or other yet to be developed handlers), I believe that unless we end up with a centralized index (like plugin manager does with XML file), we really need to separate the metadata protocol from the payload protocol.<br><br></div><div class="gmail_extra">Of course, this should be an optional override: if there is no change of protocol for a particular collection, the handler will just use the repo's protocol, but for the ZIP file if we do not want to download the whole zip just to be able to read the metadata, there is no other way than to provide a distinct metadata URL.<br><br></div><div class="gmail_extra">Additionally, I believe that providing a ZIP handler is very important, since it will likely become the most popular way to share resources, everybody is able to build a zip file and put it online, without even knowing what GIT is.<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The algorithm could be:<br><br></div><div class="gmail_extra"># Browsing:<br></div><div class="gmail_extra">- for each the repo url:<br></div><div class="gmail_extra"> - if it does not point to a metadata.ini file<br> - get the metadata address from the URL<br></div><div class="gmail_extra"> - if we have an handler to retrieve the metadata.ini<br></div><div class="gmail_extra"> - retrieve the metadata.ini<br></div><div class="gmail_extra"> - else<br></div><div class="gmail_extra"> - error<br></div><br></div>#Installing<br></div>- if the metadata does not contain a download URL for the collection<br></div> - build the collection download URL from the repo URL and protocol and collection name<br></div>- if we have an handler to retrieve the collection<br></div> - download and install<br></div>- else<br></div> - error<br><br><div><div><div><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers<span class="HOEnZb"><font color="#888888"><br><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">-- <br><div>Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></font></span></div></div></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><p><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-------------------</span></b></p><b>Akbar Gumbira </b></div><div><b style="font-size:12.8px"><a href="http://www.akbargumbira.com" target="_blank">www.akbargumbira.com</a></b></div></div></div></div></div>
</div>