<div dir="ltr">My first reaction is "please KISS", the XML project is already complicated, so I would stick to option 1.<div>About usability, I really don't mind it. Having a zipped file is convenient when... I make a mess, editing the project file.</div><div>There is already an enhancement proposal to optionally save the project to the database, it could be a good start for option 2, but the project is stored as raw content to accomodate future changes in any direction.</div><div>Here are my two cents: don't try to automate everything, sometimes a touch of vi saves your day, and above all don't make it overly complicated for automation sake.</div><div>c</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 21, 2019 at 2:41 PM Hugo Mercier <<a href="mailto:hugo.mercier@oslandia.com">hugo.mercier@oslandia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 21/01/2019 14:19, Régis Haubourg wrote:<br>
> Hi all,<br>
> <br>
> The initial plan - discussed some years ago on the lists - was to have a<br>
> container so that we can embed resources along the project file, and<br>
> open the door to a lot of nice features for sharing qgis projects.<br>
> The auxiliary data work was the opportunity to add this optional format<br>
> and checks the associated issues.<br>
> Then the idea was to switch to qgz by default and add features to save<br>
> resources (svg, fonts, datasets, etc...) into the project file.<br>
> <br>
> Unfortunately, the expected funding was discontinued and we are stuck<br>
> now with this default QGZ format, only storing the qgs and the qgd<br>
> files. (I think one should not hire a QGIS funder and expect fundings<br>
> keep coming afterwards :) )<br>
> <br>
> The timing was bad also, because we only start since a few weeks to have<br>
> user feedback on this, like this issue <a href="https://issues.qgis.org/issues/20828" rel="noreferrer" target="_blank">https://issues.qgis.org/issues/20828</a><br>
> <br>
> We also have feeback that QGZ makes things more complicated for qgs<br>
> maintenance tasks.<br>
> <br>
> I really don't know what to do:<br>
> <br>
> - switch back to classical qgs and let qgz get maturity. (But I'm afraid<br>
> we'll have very few real feedback then, just like during 3.0-3.2 period)<br>
> - give up qgz and bet on another option to offer a container (geopackage )<br>
> - totally switch to qgz and offer a python lib for easing maintenance<br>
> tasks ?<br>
<br>
I would vote for your 3rd proposition: replace xml hacking by something<br>
that looks like calls to an API.<br>
And adding an option for those who want to switch back to .qgs +<br>
separated aux files, keeping the default to .qgz.<br>
<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">--------------------------------------------------------------------------<br>Carlo A. Bertelli<br> Charta servizi e sistemi per il territorio e la storia ambientale srl <br> Dipendenze del palazzo Doria, <br> vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)<br> tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711<br> e-mail: <a href="mailto:bertelli@chartasrl.eu" target="_blank">bertelli@chartasrl.eu</a> <a href="http://www.chartasrl.eu" target="_blank">http://www.chartasrl.eu</a><br>--------------------------------------------------------------------------<br><br><br><br></div>