<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-06-20 8:15 GMT+02:00 Stefan Keller <span dir="ltr"><<a href="mailto:sfkeller@gmail.com" target="_blank">sfkeller@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Akbar and Régis<br>
<br>
Thanks for your answers.<br>
<span class=""><br>
2016-06-19 23:09 GMT+02:00 Akbar Gumbira <<a href="mailto:akbargumbira@gmail.com">akbargumbira@gmail.com</a>>:<br>
> I just read your All-In-One Project Plugin documentation here (are you about<br>
> to develop it? or already developed it?).<br>
<br>
</span>Development has been suspended in 2015 (similar but independently to<br>
relocator, QConsolidate) as documented here<br>
<a href="http://giswiki.hsr.ch/All-in-one_Project_QGIS_Plugin" rel="noreferrer" target="_blank">http://giswiki.hsr.ch/All-in-one_Project_QGIS_Plugin</a><br>
<span class=""><br>
> I think more or less the goal<br>
> would be the same with current GSoC project if we extend the definition of<br>
> 'collection' to also contain data itself. So one colleciton is a<br>
> self-sufficient QGIS resources (including its data) to create a coherent map<br>
> design.<br></span></blockquote><div><br><br></div><div>Hi Stefan, <br><br></div><div>thank you for your inputs, with this GSOC we are trying to design a system for sharing generic "resources", without any limitation on their type.<br><br></div><div>Of course the GSOC project has its own limited resources in terms of time and goals, but if the design principles will be respected, it will perfectly possible to add more resource types (like data) in the future.<br><br></div><div>The general architecture will have repository handlers (to manage different type of remote/local repositories) and resource handlers to manage the different type of resources, the resource handlers will have pre/post processing filters to handle particular cases of resource manipulation in case we need to alter the resources (think of the paths or the connection strings) when we import them into the user's QGIS instance.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>...<br>
<span class="">>> I would suggest you to read the current plan here (it<br>
>> would be long to explain in this email)<br>
>> <a href="https://docs.google.com/document/d/13ETuLBTx5IjVejB8TQPjjsMWBcUQO6pIKrNSrAZUApo/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/13ETuLBTx5IjVejB8TQPjjsMWBcUQO6pIKrNSrAZUApo/edit?usp=sharing</a><br>
<br>
</span>I would appreciate if you can extend your project to adapt this use case.<br>
But read carefully what I tried to describe (see especially the issues<br>
mentioned in my wiki page)<br>
And be cautious not to overload your project.<br>
<span class="HOEnZb"></span><br clear="all"></blockquote></div><br><br></div><div class="gmail_extra">We discussed a lot about the issues and use cases, some of them need to be addressed in the core of QGIS (the relative/absolute paths of sybols, the fonts etc.) and they are far too difficult and time consuming for this GSOC, but we are trying to keep in mind the whole big picture when working on this new sharing system and we are trying  to avoid any hardcoded blocker for future expansions.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Feel free to have a look to the code and participate directly to this project if you feel like that and if you have time/resources for helping us.<br><br></div><div class="gmail_extra">Thanks!<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>