[Qgis-developer] Report 10 - QGIS Resources Sharing Tools

[Akbar Gumbira]

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 <apasotti at gmail.com>
wrote:

> On Mon, Aug 1, 2016 at 10:17 AM, Akbar Gumbira <akbargumbira at 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>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160801/3258e36b/attachment.html>