Re: [Qgis-developer] Cleaning up the QEP list

[Neumann, Andreas]

Hi Nathan, 

no problem. Just wanted to send you some input. Hopefully it helps. You
are doing a lot for the project and I understand that during 2.16 you
were focused on the styling dock. 

As always: thanks for your efforts! 

Andreas 

On 2016-08-01 01:26, Nathan Woodrow wrote:

> Hey Andreas, 
> 
> Thanks for raising it as a issue.  I will have a look this week and do some 
> clean up.  I think I will make some more labels to show better status.  
> 
> Sorry for the lack of focus on them. 
> 
> Regards,
> Nathan 
> 
> On Mon, Jul 25, 2016 at 7:17 PM, Neumann, Andreas  wrote:
> 
>> Hi all, Hi Nathan, 
>> 
>> I am looking at the QEPs from time to time that and I think it needs a 
>> little attention. Quite a few proposals would be ready to make a decision. 
>> Some QEPs are ready but lack funding. Perhaps we can introduce a new label 
>> stating "Needs funds" or something similar? It would help potential funders 
>> to pick things they like to see implemented. Quite a few of the proposals 
>> are already implemented, sometimes even if they don't have the "Accepted 
>> label" - i guess some of the implementations had time pressure due to the 
>> 2.16 list and thus couldn't wait for voting/acceptance. 
>> 
>> Devs want to start working on many of the issues mentioned in the QEPs - so 
>> decisions need to be taken in a timely manner. 
>> 
>> Here are some of my personal suggestions for changes / closings: 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/42 (Compulsory 
>> Unit Tests for Core Changes) - discussion stalled - but I think now would be 
>> the perfect timing to implement this proposal. 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/40 (Geometry 
>> redesign) - was implemented already 2 or 3 versions ago - should be accepted 
>> and closed 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/59 (aggregate 
>> functions) is accepted, implemented - it can be closed 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/58 (QGIS Styles, 
>> Symbols ans SVG Markers Sharing Repository) - is currently being implemented 
>> by Akbar - shouldn't it be voted on/accepted? 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/53 (WFS provider 
>> enhancements) - is already implemented and should be closed 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/49 (Label mask) 
>> - would be ready to implement, but lacks funding (add the new "Needs funds" 
>> label?) 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/46 (Labling 
>> path) - would be ready to implement, but lacks funding (add the new "Needs 
>> funds" label?) 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/45 (Long term 
>> releases) - implemented - should be closed 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/43 (Rename 
>> Compositions to Print Layouts) - would be good to be addressed during work 
>> for 3.x - can we continue discussion and vote on it? 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/39 (Layout 
>> rework (composer v2)) - Nyall wants to start on this - so it should be 
>> discussed and accepted 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/38 (Inheritable 
>> property collections) - unsure about the status here, apparently it has a 
>> prototype implementation. How does this relate to the variable system 
>> introduced recently? 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/37 (Fields and 
>> Forms Redesign) - would be a good candidate to be implemented during QGIS 
>> 3.x - probably lacks funding 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/35 
>> (Authentication configuration system with master password) - already 
>> implemented. Should be accetped and closed. 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/32 (Add QGIS 
>> server access control interface for python plugins) - already implemented. 
>> Should be accepted and closed: 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/31 (QGIS Legal 
>> Entity) - accepted by Loomio vote and mostly implemented. Should be acepted 
>> and closed. 
>> 
>> - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29 (QGIS 3.0) - 
>> discussion maybe a bit outdated? Close? 
>> 
>> It would be good, if we, as the project would take the QEPs a bit more 
>> seriously and maintain them accordingly. Seems like some devs do, some 
>> don't. Any comments? 
>> 
>> Thanks and greetings, 
>> 
>> Andreas

  ___
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

[Qgis-developer] Call for proposals: QGIS Grant programme August 2016

[Tim Sutton]

Hi All

The QGIS project is pleased to announce the first QGIS Grant programme. If you 
are a developer of community contributor and would like to be funded to work on 
that great improvement to QGIS that you have been dreaming of, now is your 
chance!

Please visit : https://goo.gl/forms/ADDuYhlgWS9UlKe82 
 for details.

Regards

Tim



---

Tim Sutton
QGIS Project Steering Committee Chair
t...@qgis.org




___
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

Re: [Qgis-developer] * Important* Preparations for QGIS Developer Meeting in Bonn

[Otto Dassau]

Hi,

we are now about 30 people on the wiki lists for the hackfest in Bonn and we
added some more accomodations to the github wiki:

https://wiki.osgeo.org/wiki/FOSS4G_2016_Code_Sprint#Registered_Attendees
https://github.com/qgis/QGIS/wiki/QGIS-Hackfest---Bonn---August-2016

but I have heard, that there are still people missing on the wiki list and
there are also still (about 10-15) people looking for accomodation. Please
add your names (also important for us to organize the dinner).

We are in contact with places close to the basecamp. If you need help,
please send an email directly to me, so I can organize something for you.

Regards,
Otto


Am Thu, 21 Jul 2016 12:00:00 +0200
schrieb Otto Dassau :

> Hi,
> 
> we started to prepare our own QGIS wiki page to organize the upcoming
> hackfest in Bonn and to make sure that our hackfest will be fun. Many of
> you already registered at foss4g wiki page at
> 
> https://wiki.osgeo.org/wiki/FOSS4G_2016_Code_Sprint#Registered_Attendees
> 
> and I tried already to put it in sync this with our new internal page at
> 
> https://github.com/qgis/QGIS/wiki/QGIS-Hackfest---Bonn---August-2016
> 
> But I need your help and would like to ask you to do the following for us:
> 
> a) If you want to participate, please register twice in the FOSS4G Wiki and
> in the QGIS Wiki. This is important to have a smooth organisation on QGIS
> and FOSS4G side.
> 
> b) If you already registered at one of the pages, please check again and
> make sure you appear in both lists.
> 
> To organize further accomodation and our well-known dinner, we need your
> information as quick and as complete as possible.
> 
> Thanks a lot
> Otto
> ___
> 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

___
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

Re: [Qgis-developer] strange GetCapabilities caching

[Jeff McKenna]

Hi Nicklas,

Just a heads up that this is still an issue with 2.16.0; however now it 
seems to be even worse now:


 - the "Clear" button for clearing the cache has now been changed to an 
icon with arrows, that is confusing to the user.  I think a button with 
the words "Clear Cache" makes more sense.
 - I just now spent 4 hours trying to get a service to appear in QGIS, 
and the issue was that pressing the clear cache icon in QGIS 2.16.0 
wasn't actually clearing the cache: I had to go into 
C:/Users/Jeff/.qgis/cache/data7/ and manually delete the contents of 
that folder, and magically my WMS service worked in QGIS


Keep your heads up for that issue.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/

On 2016-03-28 3:16 PM, Nicklas Avén wrote:

Hallo all

First, Thanks a lot for QGIS and QGIS Server. It is  amazing software.

But now I have had a very frustrating problem for the last 5 hours.

After setting up a working QGIS server a few weeks ago, I now returned
to see everything working after some major refactoring at the database.

Nothing worked, and after some hours I started to get really frustrated
since we have just a few weeks until we go in production and I really
don't want to replace QGIS Server because of unpredictable behavior.

The error I had was:
Invalid Layer: WMS provider Cannot calculate extent Raster layer
Provider is not valid (provider: wms, URI:
contextualWMSLegend=0=EPSG:4326=7=10 ...

on all layers but one.

I saw this question was asked several times at the net, but no one
seemed to have had any answer:
https://hub.qgis.org/issues/10634
https://hub.qgis.org/issues/7712
http://osgeo-org.1560.x6.nabble.com/qgisserver-problem-td5095165.html


The last link solved it by a fresh install and now I understand why.

Finally I found the answer
http://osgeo-org.1560.x6.nabble.com/WMS-provider-Cannot-calculate-extent-td5250516.html

But the OP didn't get an answer of his follow up question: Why the h...
is the GetCapabilities cached?

I ask the same thing, especially since a new version of GetCapabilities
is also fetched.

This is what made me use 5 hours on debugging (including turning the
server inside out, both database and uwsgi, nginx and so on).

The layers presented when connecting to the wms server was fresh and
new. But it seems like, when I tried to add the layer it used a cached
GetCapabilities, which didn't correspond to my new setup on the server.

I could also sniff the GetCapabilities request. But I also saw that no
request was made when I tried to add the layer. So, now when I see the
whole picture I look rather stupid, but I couldn't imagine that I had
fresh data when connecting, but old data when trying to add the map.

Another thing that made things bad was the error message just flashing
on the top of my map. It didn't write anything to the log windows from
what I could see, and the message was shown in a too thin box. So I had
to try to add the layer, quickly close the "Add WMS window" and copy the
text in the too thin box to be able to read it.

Sorry for my frustrated tone. I still really love QGIS. But software
(any software) can drive you crazy sometimes.

I also suspect that I might get into exactly the same trap after a few
months when i have forgotten this. I hope I find this mail then on my
googling :-)

Regards

Nicklas Avén





___
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

[Qgis-developer] Processing-R multiple fields error

[matteo]

Hi all,

a couple of days ago I reported a bug in when creating an R script and
one of the input is `ParameterTableMultipleField` [0].

I had a look at the code an maybe I solved a part of the issue, that is
the algorithm GUI does not complain anymore.

But I'm sill not able to use the outputs of that parameter. If I load
some random Fields and I just try to print them in the R console, I get
this error:

Source:
"/tmp/processing8e0411a7ebc64ffc9f75b69d1f7e1f5e/f3653d7497eb4d62b0ffaf62c7a5631c",
layer: "dataexp"
with 102 features
It has 6 fields
multiple field Layer="SN;Y"
Error: unexpected symbol in "multiple field"
Execution halted


Here the piece of the super simple R script:
##Basic statistics=group
##Layer=vector
##Field=multiple field Layer
>Field


And the fixes of Processing are here [1]. Just one file, an import
missing and a small import problem (file is
processing/gui/ListMultiselectWidget)


Anybody has an idea? This could be a super feature to have

Thanks

Matteo


[0]
http://osgeo-org.1560.x6.nabble.com/Processing-R-script-parameters-error-td5278137.html
[1] https://gist.github.com/ghtmtt/4e6d40505c1312c85e23849f468de542
___
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

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

[Matthias Kuhn]

Hi Akbar,

Do you really need a flag? I think you can just check if the scheme is
specified in the URI. If it's missing, assume the same protocol.

Cheers

On 08/01/2016 11:35 AM, Akbar Gumbira wrote:
> Hi Matthias,
> 
> I think I missed your point before. I think I will add a flag in the
> metadata that users need to put, to state whether the repository is
> using the same protocol as the metadata or not. This way it could be
> more portable to use the repository in different protocol. For example
> users can clone a repository from git and use that repository in the
> local without having to change the metadata file itself.
> 
> Cheers
> 
> 
> 
> On Mon, Aug 1, 2016 at 11:13 AM, Akbar Gumbira  > wrote:
> 
> Hi Matthias,
>  
> 
> I guess support for relative URLs should be trivial and make the
> repositories more portable. And as far as I can see it should be
> possible to have relative and absolute paths side-by-side, no?
> 
> If it's a matter of portability, users can still put the metadata
> inside the repository itself (if they put the repository in a
> directory based e.g git/local file system). It's just that they need
> to explicitly put the metadata URI in the settings when adding a
> repository. 
> 
> If users want to make a zip collections, they need to put the
> metadata somewhere else outside the zip. I agree with Ale though
> that most users probably prefer this, they can just put a zip and
> the metadata file in dropbox or google drive for example.
> 
> Cheers
> 
> On Mon, Aug 1, 2016 at 10:56 AM, Matthias Kuhn  > wrote:
> 
> Hi
> 
> > 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.
> 
> I guess support for relative URLs should be trivial and make the
> repositories more portable. And as far as I can see it should be
> possible to have relative and absolute paths side-by-side, no?
> 
> Regards
> Matthias
> ___
> 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
> 
> 
> 
> 
> -- 
> 
> *---*
> 
> *Akbar Gumbira *
> *www.akbargumbira.com *
> 
> 
> 
> 
> -- 
> 
> *---*
> 
> *Akbar Gumbira *
> *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

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

[Akbar Gumbira]

Hi Matthias,

I think I missed your point before. I think I will add a flag in the
metadata that users need to put, to state whether the repository is using
the same protocol as the metadata or not. This way it could be more
portable to use the repository in different protocol. For example users can
clone a repository from git and use that repository in the local without
having to change the metadata file itself.

Cheers



On Mon, Aug 1, 2016 at 11:13 AM, Akbar Gumbira 
wrote:

> Hi Matthias,
>
>
>> I guess support for relative URLs should be trivial and make the
>> repositories more portable. And as far as I can see it should be
>> possible to have relative and absolute paths side-by-side, no?
>
> If it's a matter of portability, users can still put the metadata inside
> the repository itself (if they put the repository in a directory based e.g
> git/local file system). It's just that they need to explicitly put the
> metadata URI in the settings when adding a repository.
>
> If users want to make a zip collections, they need to put the metadata
> somewhere else outside the zip. I agree with Ale though that most users
> probably prefer this, they can just put a zip and the metadata file in
> dropbox or google drive for example.
>
> Cheers
>
> On Mon, Aug 1, 2016 at 10:56 AM, Matthias Kuhn 
> wrote:
>
>> Hi
>>
>> > 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.
>>
>> I guess support for relative URLs should be trivial and make the
>> repositories more portable. And as far as I can see it should be
>> possible to have relative and absolute paths side-by-side, no?
>>
>> Regards
>> Matthias
>> ___
>> 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
>
>
>
>
> --
>
> *---*
> *Akbar Gumbira *
> *www.akbargumbira.com *
>



-- 

*---*
*Akbar Gumbira *
*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

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

[Akbar Gumbira]

Hi Matthias,


> I guess support for relative URLs should be trivial and make the
> repositories more portable. And as far as I can see it should be
> possible to have relative and absolute paths side-by-side, no?

If it's a matter of portability, users can still put the metadata inside
the repository itself (if they put the repository in a directory based e.g
git/local file system). It's just that they need to explicitly put the
metadata URI in the settings when adding a repository.

If users want to make a zip collections, they need to put the metadata
somewhere else outside the zip. I agree with Ale though that most users
probably prefer this, they can just put a zip and the metadata file in
dropbox or google drive for example.

Cheers

On Mon, Aug 1, 2016 at 10:56 AM, Matthias Kuhn  wrote:

> Hi
>
> > 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.
>
> I guess support for relative URLs should be trivial and make the
> repositories more portable. And as far as I can see it should be
> possible to have relative and absolute paths side-by-side, no?
>
> Regards
> Matthias
> ___
> 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




-- 

*---*
*Akbar Gumbira *
*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

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

[Matthias Kuhn]

Hi

> 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.

I guess support for relative URLs should be trivial and make the
repositories more portable. And as far as I can see it should be
possible to have relative and absolute paths side-by-side, no?

Regards
Matthias
___
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

Re: [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 
wrote:

> On Mon, Aug 1, 2016 at 10:17 AM, Akbar Gumbira 
> 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 *
___
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

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

[Alessandro Pasotti]

On Mon, Aug 1, 2016 at 10:17 AM, Akbar Gumbira 
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
___
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

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

[Alessandro Pasotti]

On Sat, Jul 30, 2016 at 10:39 PM, Akbar Gumbira 
wrote:

> *What did you get done this week?*
>
>- *Implemented style resource handler*
>
> User can now also put style (qml file) in the collection.
>
>
>- *Fixed issues on windows*
>
> 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)
>
>
>- *Wrote some documentation* (
>http://www.akbargumbira.com/qgis_resources_sharing/)
>
>
>- *Implemented file system handler*
>
> User can now use repository in the local file system. The URI should have
> this format: file://. On Windows it looks something
> like this *file://C:/home/akbar/repo. *On linux: *file:///home/akbar/repo*
> .
> This could be useful for:
>
>
>- 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)
>   - In case someone wants to use private repo, they can pull it to
>   their local machine, and just use that local clone
>   - Sharing the repository on the network
>
> *What do you plan on doing next week?*
>
>- Documentation and unittests
>- 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)
>- 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.
>
>
> *Are you blocked on anything?*
> No, just need to have more opinions on the situation I mentioned above.
>
> Have a nice weekend. Cheers!
> --
>


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.

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.

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.

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.


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