[Qgis-developer] Report 5 - QGIS Symbology Sharing Tools

[Akbar Gumbira]

Hi,

I made a video of the progress so far:
https://www.youtube.com/watch?v=OmJ2Vh3a63U


*What did you get done this week?*

   - Saving the metadata of the collections to local as a cache (after some
   operations like adding/removing/deleting repository) so that when user
   doesn't have internet, (s)he will still be able to browse collection.
   - Filtering collections with custom QSortFilterProxyModel to allow
   filtering based on author, name, description, etc.
   - Fix unicode problem (The problem is when parsing the metadatafile.
   Using ConfigParser it was read as str. Changed it to SafeConfigParser with
   codecs module)
   - Implemented reload repositories. Also when fetching metadata, never
   use cache
   - Implemented Ale's suggestion to have a directory file in official
   repository and containing available repositories (and by default all those
   repositories will be registered in the plugin)
   - Still thinking to use git as it will be more efficient rather than
   using zip url and tried Dulwich (Python pure git implementation), but it's
   freezing the UI (see the video above)

*What do you plan on doing next week?*

   - My code is getting harder to read. Need to refactor some and make tests
   - Tried to load a repository that contains 1000 collections. Right now,
   I just saved the metadata's cache (dict) to the qsettings. The QGIS config
   file is getting too big. WIll move this to a separate pickled file.
   - Explored Dulwich more


Are you blocked on anything?
I have problem with Dulwich. It's freezing the UI. I want to show the
progress of cloning/pulling repository realtime but I haven't figured out a
way yet.

-- 

*---*
*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 5 - QGIS Symbology Sharing Tools

[Matthias Kuhn]

Hi Akbar,

thanks a lot for the update, I especially liked the video, this makes it
a lot easier for the audience (at least me :) ) to get an impression of
the status quo. Good job so far!

Concerning dulwich, did you checkout the #dulwich IRC channel and the
mailing list which are mentioned in the project's readme [1] ?

What exactly are the efficiency problems you are referring to? Maybe
it's also worth looking into downloading individual files over http
instead of the whole .zip file (raw.githubusercontent.com), that also
allows doing partial downloads if you don't need a complete repository
and you know which files you want.

Looking forward to hearing more of this project, keep up the good work!

Matthias

[1] https://github.com/jelmer/dulwich#help

On 06/26/2016 07:10 PM, Akbar Gumbira wrote:
> Hi,
> 
> I made a video of the progress so
> far: https://www.youtube.com/watch?v=OmJ2Vh3a63U
> 
> 
> *What did you get done this week?*
> 
>   * Saving the metadata of the collections to local as a cache (after
> some operations like adding/removing/deleting repository) so that
> when user doesn't have internet, (s)he will still be able to browse
> collection.
>   * Filtering collections with custom QSortFilterProxyModel to allow
> filtering based on author, name, description, etc.
>   * Fix unicode problem (The problem is when parsing the metadatafile.
> Using ConfigParser it was read as str. Changed it to
> SafeConfigParser with codecs module)
>   * Implemented reload repositories. Also when fetching metadata, never
> use cache
>   * Implemented Ale's suggestion to have a directory file in official
> repository and containing available repositories (and by default all
> those repositories will be registered in the plugin)
>   * Still thinking to use git as it will be more efficient rather than
> using zip url and tried Dulwich (Python pure git implementation),
> but it's freezing the UI (see the video above)
> 
> *What do you plan on doing next week?*
> 
>   * My code is getting harder to read. Need to refactor some and make tests
>   * Tried to load a repository that contains 1000 collections. Right
> now, I just saved the metadata's cache (dict) to the qsettings. The
> QGIS config file is getting too big. WIll move this to a separate
> pickled file.
>   * Explored Dulwich more
> 
> 
> Are you blocked on anything?
> I have problem with Dulwich. It's freezing the UI. I want to show the
> progress of cloning/pulling repository realtime but I haven't figured
> out a way yet.
> 
> -- 
> 
> *---*
> 
> *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
> 
___
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 5 - QGIS Symbology Sharing Tools

[Akbar Gumbira]

Hi Matthias,

Thanks for the feedback. Unfortunately raw URL is only provided for a
single file, not a directory. As one repository could have many collections
(collection is a directory containing resources), with git protocol, there
are 2 ways downloading a single collection from a repository: git sparse
checkout and git archive. Sparse checkout is not supported in Dulwich nor
in Pygit2 (a Python wrapper using libgit2). And with the 2nd option, Github
doesn't allow git archive.

One other alternative (which I am exploring now) is to clone a repository
the first time user downloads a collection from that repository, and next
time user downloads other collections from that repository, we just need to
update and pull that repository. This is more efficient compared to
downloading the whole repository (using zip url) every time user wants to
download a collection.

We came to the decision that one repository could have many collections in
the first place as it doesn't make sense  (we thought) for users to create
one repository only for one collection.

Cheers

On Sun, Jun 26, 2016 at 7:50 PM, Matthias Kuhn  wrote:

> Hi Akbar,
>
> thanks a lot for the update, I especially liked the video, this makes it
> a lot easier for the audience (at least me :) ) to get an impression of
> the status quo. Good job so far!
>
> Concerning dulwich, did you checkout the #dulwich IRC channel and the
> mailing list which are mentioned in the project's readme [1] ?
>
> What exactly are the efficiency problems you are referring to? Maybe
> it's also worth looking into downloading individual files over http
> instead of the whole .zip file (raw.githubusercontent.com), that also
> allows doing partial downloads if you don't need a complete repository
> and you know which files you want.
>
> Looking forward to hearing more of this project, keep up the good work!
>
> Matthias
>
> [1] https://github.com/jelmer/dulwich#help
>
> On 06/26/2016 07:10 PM, Akbar Gumbira wrote:
> > Hi,
> >
> > I made a video of the progress so
> > far: https://www.youtube.com/watch?v=OmJ2Vh3a63U
> >
> >
> > *What did you get done this week?*
> >
> >   * Saving the metadata of the collections to local as a cache (after
> > some operations like adding/removing/deleting repository) so that
> > when user doesn't have internet, (s)he will still be able to browse
> > collection.
> >   * Filtering collections with custom QSortFilterProxyModel to allow
> > filtering based on author, name, description, etc.
> >   * Fix unicode problem (The problem is when parsing the metadatafile.
> > Using ConfigParser it was read as str. Changed it to
> > SafeConfigParser with codecs module)
> >   * Implemented reload repositories. Also when fetching metadata, never
> > use cache
> >   * Implemented Ale's suggestion to have a directory file in official
> > repository and containing available repositories (and by default all
> > those repositories will be registered in the plugin)
> >   * Still thinking to use git as it will be more efficient rather than
> > using zip url and tried Dulwich (Python pure git implementation),
> > but it's freezing the UI (see the video above)
> >
> > *What do you plan on doing next week?*
> >
> >   * My code is getting harder to read. Need to refactor some and make
> tests
> >   * Tried to load a repository that contains 1000 collections. Right
> > now, I just saved the metadata's cache (dict) to the qsettings. The
> > QGIS config file is getting too big. WIll move this to a separate
> > pickled file.
> >   * Explored Dulwich more
> >
> >
> > Are you blocked on anything?
> > I have problem with Dulwich. It's freezing the UI. I want to show the
> > progress of cloning/pulling repository realtime but I haven't figured
> > out a way yet.
> >
> > --
> >
> > *---*
> >
> > *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
> >
> ___
> 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 5 - QGIS Symbology Sharing Tools

[Matthias Kuhn]

Hi Akbar

On 06/27/2016 11:32 AM, Akbar Gumbira wrote:
> Hi Matthias, 
> 
> Thanks for the feedback. Unfortunately raw URL is only provided for a
> single file, not a directory.

Couldn't all the files be downloaded individually?
This will result in a couple of additional requests, but I'm not sure
this is something to worry about.
The main question would then be, where the client could retrieve the
file list (paths relative). Generating this list could be part of the
upload script.

> As one repository could have many
> collections (collection is a directory containing resources), with git
> protocol, there are 2 ways downloading a single collection from a
> repository: git sparse checkout and git archive. Sparse checkout is not
> supported in Dulwich nor in Pygit2 (a Python wrapper using libgit2). And
> with the 2nd option, Github doesn't allow git archive.
> 
> One other alternative (which I am exploring now) is to clone a
> repository the first time user downloads a collection from that
> repository, and next time user downloads other collections from that
> repository, we just need to update and pull that repository. This is
> more efficient compared to downloading the whole repository (using zip
> url) every time user wants to download a collection.

Is the plan to mainly have users create their own repositories (and then
manually enter the path to them in the style manager - or have a
repository of repositories :) )?
Or to have one main repository with many collections (like currently
with the plugins)?

If it's the first, I wouldn't care too much about the couple of extra
bytes downloaded.
If it's the second, that may result in some huge download and disk space
consumption caused by one or a few collections.

Cheers
Matthias

> 
> We came to the decision that one repository could have many collections
> in the first place as it doesn't make sense  (we thought) for users to
> create one repository only for one collection.
> 
> Cheers
> 
> On Sun, Jun 26, 2016 at 7:50 PM, Matthias Kuhn  > wrote:
> 
> Hi Akbar,
> 
> thanks a lot for the update, I especially liked the video, this makes it
> a lot easier for the audience (at least me :) ) to get an impression of
> the status quo. Good job so far!
> 
> Concerning dulwich, did you checkout the #dulwich IRC channel and the
> mailing list which are mentioned in the project's readme [1] ?
> 
> What exactly are the efficiency problems you are referring to? Maybe
> it's also worth looking into downloading individual files over http
> instead of the whole .zip file (raw.githubusercontent.com
> ), that also
> allows doing partial downloads if you don't need a complete repository
> and you know which files you want.
> 
> Looking forward to hearing more of this project, keep up the good work!
> 
> Matthias
> 
> [1] https://github.com/jelmer/dulwich#help
> 
> On 06/26/2016 07:10 PM, Akbar Gumbira wrote:
> > Hi,
> >
> > I made a video of the progress so
> > far: https://www.youtube.com/watch?v=OmJ2Vh3a63U
> >
> >
> > *What did you get done this week?*
> >
> >   * Saving the metadata of the collections to local as a cache (after
> > some operations like adding/removing/deleting repository) so that
> > when user doesn't have internet, (s)he will still be able to browse
> > collection.
> >   * Filtering collections with custom QSortFilterProxyModel to allow
> > filtering based on author, name, description, etc.
> >   * Fix unicode problem (The problem is when parsing the metadatafile.
> > Using ConfigParser it was read as str. Changed it to
> > SafeConfigParser with codecs module)
> >   * Implemented reload repositories. Also when fetching metadata,
> never
> > use cache
> >   * Implemented Ale's suggestion to have a directory file in official
> > repository and containing available repositories (and by default all
> > those repositories will be registered in the plugin)
> >   * Still thinking to use git as it will be more efficient rather than
> > using zip url and tried Dulwich (Python pure git implementation),
> > but it's freezing the UI (see the video above)
> >
> > *What do you plan on doing next week?*
> >
> >   * My code is getting harder to read. Need to refactor some and
> make tests
> >   * Tried to load a repository that contains 1000 collections. Right
> > now, I just saved the metadata's cache (dict) to the qsettings. The
> > QGIS config file is getting too big. WIll move this to a separate
> > pickled file.
> >   * Explored Dulwich more
> >
> >
> > Are you blocked on anything?
> > I have problem with Dulwich. It's freezing the UI. I want to show the
> > progress of cloning/pulling repository realtime but I haven't 

Re: [Qgis-developer] Report 5 - QGIS Symbology Sharing Tools

[Vincent Picavet (ml)]

Hello,


On 27/06/2016 12:41, Matthias Kuhn wrote:
> On 06/27/2016 11:32 AM, Akbar Gumbira wrote:
>> Thanks for the feedback. Unfortunately raw URL is only provided for a
>> single file, not a directory.
> 
> Couldn't all the files be downloaded individually?
> This will result in a couple of additional requests, but I'm not sure
> this is something to worry about.
> The main question would then be, where the client could retrieve the
> file list (paths relative). Generating this list could be part of the
> upload script.

I may be late to the party, but I really do not get the point of using
git here for data retrieval.
And furthermore, I wouldn't want QGIS to have a hard dependency on git,
which is a developer tool users are not supposed to have installed by
default.

If you want to focus on the client part of the feature and not implement
a resource server, maybe a simpler approach would be better for a start.

Why not having a metadata file (JSON or XML) listing the resources
provided by the repository, and then the raw files at specified urls.
All of this served by a bare HTTP server, no more no less.
If some want to manage versioning of the resources and use github for
that, they can use the site generation tool (github pages) to do so.
Easy and lightweight. Or if we do not want to depend on a proprietary
platform, just generate the metadata+data files on any HTTP hosting
platform.
And we can later write a full resource server in our language of choice
to dynamically serve resources and metadata.

My 2 cents, sorry if this has been discussed before.

Vincent

> 
>> As one repository could have many
>> collections (collection is a directory containing resources), with git
>> protocol, there are 2 ways downloading a single collection from a
>> repository: git sparse checkout and git archive. Sparse checkout is not
>> supported in Dulwich nor in Pygit2 (a Python wrapper using libgit2). And
>> with the 2nd option, Github doesn't allow git archive.
>>
>> One other alternative (which I am exploring now) is to clone a
>> repository the first time user downloads a collection from that
>> repository, and next time user downloads other collections from that
>> repository, we just need to update and pull that repository. This is
>> more efficient compared to downloading the whole repository (using zip
>> url) every time user wants to download a collection.
> 
> Is the plan to mainly have users create their own repositories (and then
> manually enter the path to them in the style manager - or have a
> repository of repositories :) )?
> Or to have one main repository with many collections (like currently
> with the plugins)?
> 
> If it's the first, I wouldn't care too much about the couple of extra
> bytes downloaded.
> If it's the second, that may result in some huge download and disk space
> consumption caused by one or a few collections.
> 
> Cheers
> Matthias
> 
>>
>> We came to the decision that one repository could have many collections
>> in the first place as it doesn't make sense  (we thought) for users to
>> create one repository only for one collection.
>>
>> Cheers
>>
>> On Sun, Jun 26, 2016 at 7:50 PM, Matthias Kuhn > > wrote:
>>
>> Hi Akbar,
>>
>> thanks a lot for the update, I especially liked the video, this makes it
>> a lot easier for the audience (at least me :) ) to get an impression of
>> the status quo. Good job so far!
>>
>> Concerning dulwich, did you checkout the #dulwich IRC channel and the
>> mailing list which are mentioned in the project's readme [1] ?
>>
>> What exactly are the efficiency problems you are referring to? Maybe
>> it's also worth looking into downloading individual files over http
>> instead of the whole .zip file (raw.githubusercontent.com
>> ), that also
>> allows doing partial downloads if you don't need a complete repository
>> and you know which files you want.
>>
>> Looking forward to hearing more of this project, keep up the good work!
>>
>> Matthias
>>
>> [1] https://github.com/jelmer/dulwich#help
>>
>> On 06/26/2016 07:10 PM, Akbar Gumbira wrote:
>> > Hi,
>> >
>> > I made a video of the progress so
>> > far: https://www.youtube.com/watch?v=OmJ2Vh3a63U
>> >
>> >
>> > *What did you get done this week?*
>> >
>> >   * Saving the metadata of the collections to local as a cache (after
>> > some operations like adding/removing/deleting repository) so that
>> > when user doesn't have internet, (s)he will still be able to browse
>> > collection.
>> >   * Filtering collections with custom QSortFilterProxyModel to allow
>> > filtering based on author, name, description, etc.
>> >   * Fix unicode problem (The problem is when parsing the metadatafile.
>> > Using ConfigParser it was read as str. Changed it to
>> > SafeConfigParser with codecs module)
>> >  

Re: [Qgis-developer] Report 5 - QGIS Symbology Sharing Tools

[Richard Duivenvoorde]

On 27-06-16 18:28, Vincent Picavet (ml) wrote:
> On 27/06/2016 12:41, Matthias Kuhn wrote:
>> > On 06/27/2016 11:32 AM, Akbar Gumbira wrote:
>>> >> Thanks for the feedback. Unfortunately raw URL is only provided for a
>>> >> single file, not a directory.
>> > 
>> > Couldn't all the files be downloaded individually?
>> > This will result in a couple of additional requests, but I'm not sure
>> > this is something to worry about.
>> > The main question would then be, where the client could retrieve the
>> > file list (paths relative). Generating this list could be part of the
>> > upload script.
> I may be late to the party, but I really do not get the point of using
> git here for data retrieval.
> And furthermore, I wouldn't want QGIS to have a hard dependency on git,
> which is a developer tool users are not supposed to have installed by
> default.

Hi Vincent,

There has been some (a lot of) discussion indeed already :-)

But the main idea of using git was to have lively updated
style/symbol/data repositories: by keeping users repo's as
personal/named style repo's they would get credit for their work. They
could 'just' do this by starting a repo on Github/Bitbucket/Gitlab. So
somebody could clone a repo, add one individual icon to it, and maybe
one updated style and do a pull request.
Using git then we would have an 'easy' way to update the users local
repo's with only those files that were updated.
If I'm correct we would not need a git install, there is also a native
python-git version which could be used as module.

But thinking about this more, your options is also valid: another
strategy would be split up the work in:
-1- serving static files (with a version number in the metadata?) to
serve out the stuff on a http server
-2- have the files in git repo's for the administration of it: add stuff
via pr's etc...

Off course a lot of possible solutions are ok :-(

Regards,

Richard

___
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 5 - QGIS Symbology Sharing Tools

[Régis Haubourg]

Hi,
I tend to think that git / github workflow could be too high technician for
most users that have not developer's culture. This is how I see it for
processing script sharing today.. but processing is mostly concerning devs
when styling is a lot wider.
Why not combine both? Gist or equivalent for static files and git for the
main repo where or and collaborative work is required?
Cheers Regis

Le 27 juin 2016 21:20, "Richard Duivenvoorde"  a
écrit :
>
> On 27-06-16 18:28, Vincent Picavet (ml) wrote:
> > On 27/06/2016 12:41, Matthias Kuhn wrote:
> >> > On 06/27/2016 11:32 AM, Akbar Gumbira wrote:
> >>> >> Thanks for the feedback. Unfortunately raw URL is only provided
for a
> >>> >> single file, not a directory.
> >> >
> >> > Couldn't all the files be downloaded individually?
> >> > This will result in a couple of additional requests, but I'm not sure
> >> > this is something to worry about.
> >> > The main question would then be, where the client could retrieve the
> >> > file list (paths relative). Generating this list could be part of the
> >> > upload script.
> > I may be late to the party, but I really do not get the point of using
> > git here for data retrieval.
> > And furthermore, I wouldn't want QGIS to have a hard dependency on git,
> > which is a developer tool users are not supposed to have installed by
> > default.
>
> Hi Vincent,
>
> There has been some (a lot of) discussion indeed already :-)
>
> But the main idea of using git was to have lively updated
> style/symbol/data repositories: by keeping users repo's as
> personal/named style repo's they would get credit for their work. They
> could 'just' do this by starting a repo on Github/Bitbucket/Gitlab. So
> somebody could clone a repo, add one individual icon to it, and maybe
> one updated style and do a pull request.
> Using git then we would have an 'easy' way to update the users local
> repo's with only those files that were updated.
> If I'm correct we would not need a git install, there is also a native
> python-git version which could be used as module.
>
> But thinking about this more, your options is also valid: another
> strategy would be split up the work in:
> -1- serving static files (with a version number in the metadata?) to
> serve out the stuff on a http server
> -2- have the files in git repo's for the administration of it: add stuff
> via pr's etc...
>
> Off course a lot of possible solutions are ok :-(
>
> Regards,
>
> Richard
>
> ___
> 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] Report 5 - QGIS Symbology Sharing Tools

[Alessandro Pasotti]

2016-06-27 21:45 GMT+02:00 Régis Haubourg :

> Hi,
> I tend to think that git / github workflow could be too high technician
> for most users that have not developer's culture. This is how I see it for
> processing script sharing today.. but processing is mostly concerning devs
> when styling is a lot wider.
> Why not combine both? Gist or equivalent for static files and git for the
> main repo where or and collaborative work is required?
> Cheers Regis
>

The designed architecture of the resource sharing system is protocol
independent: handlers for different repository protocols can be easily
added.

The idea is to have at least:
- filesystem (symbol repository is on filesystem, for example a network
share), this is the simplest case: a copy command is all we need to fetch
resources and update them
- git

So, git is just one of the possible handlers for remote repositories and
the idea is that the average user will never know that git is used under
the hood, it should be completely transparent.

If the general design will be respected during the implementation, it will
be really easy to expand the system to handle different remotes and
different shared resources.

The idea comes from the flexibility of python pip: it can fetch and install
resources (python packages in this case) from many different URIs, git
included.

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 5 - QGIS Symbology Sharing Tools

[Akbar Gumbira]

HI,

Yes, I am trying to explore Dulwich now (which is a pure Python
implementation of GIT). There is no need to add git dependency added to
QGIS or that user needs to have git in their computer (if Dulwich works
nicely).

And as Ale said, we would like to have 2 designs implemented here:

   - Repository handler. This should be independent to the protocol of the
   repository. In the case of filesystem, it would be just to copy the
   repository to the plugin working directory and extract the collections
   inside. I made handlers classes quite general and will be refactoring time
   to time if it's needed (now I am still working on git protocol though).
   - Resources handler. This part of the system should handle how the
   resources in the collection being imported into QGIS.

The focus on this GSoC phase is to fetch and import the collections (not
the sharing part). With this goal, it would be easier for users if we
implement in a way that they don't need to make a list of the resources in
the collections. That's why I am still looking for a solution other than
listing all the resources and fetch them one by one using HTTP request to
the git host.

Cheers

On Tue, Jun 28, 2016 at 11:09 AM, Alessandro Pasotti 
wrote:

> 2016-06-27 21:45 GMT+02:00 Régis Haubourg :
>
>> Hi,
>> I tend to think that git / github workflow could be too high technician
>> for most users that have not developer's culture. This is how I see it for
>> processing script sharing today.. but processing is mostly concerning devs
>> when styling is a lot wider.
>> Why not combine both? Gist or equivalent for static files and git for the
>> main repo where or and collaborative work is required?
>> Cheers Regis
>>
>
> The designed architecture of the resource sharing system is protocol
> independent: handlers for different repository protocols can be easily
> added.
>
> The idea is to have at least:
> - filesystem (symbol repository is on filesystem, for example a network
> share), this is the simplest case: a copy command is all we need to fetch
> resources and update them
> - git
>
> So, git is just one of the possible handlers for remote repositories and
> the idea is that the average user will never know that git is used under
> the hood, it should be completely transparent.
>
> If the general design will be respected during the implementation, it will
> be really easy to expand the system to handle different remotes and
> different shared resources.
>
> The idea comes from the flexibility of python pip: it can fetch and
> install resources (python packages in this case) from many different URIs,
> git included.
>
> 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
>



-- 

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