[GNC-dev] Deprecation of XML file

[David Carlson]

I am confused about what you are asking for.  Do you want to revise the
development roadmap?  Are you asking in an oblique way what would they
prefer you to work on?  Derek said that the log term plan was already going
in that direction, but they may have different stops planned on the way.

David Carlson

On Mon, Sep 14, 2020 at 2:39 PM Stefan Bluhm <gnucash.org at bluhm-de.com>
wrote:

> Thank you all for the feedback. Let me please summarise your demands for
> XML and comment on that (I hope I didn't leave any comments out). Always
> keep in mind that in this case we are talking SQLite as a file type, just
> like XML. Not about the DB server library.
>
> 1) A save file has less management overhead than a DB.
> > SQLite is also file based and transparent for the end user. No DB
> management required. So here is no chance a tall.
>
> 2) Save file can be distributed via fileshare.
> > SQLite is also file based and transparent for the end user. No DB
> management required. So here is no chance a tall.
>
> 3) It can be easy analyzed by a simple grep commands
> > This would become a little more complex but can be done: sqlite3
> file.gnucash .dump | grep "text"
>
> 4) It can be easy analyzed by more advanced (XSLT, XPATH,…) commands.
> > Just use any SQLite browser. I claim that is a lot easier than fighting
> with XSLT/XPATH etc (this is certainly opinion based)
>
> 5) Use rsync for fast diff based backups.
> > Should the same with an SQLite.
>
> 6) XML is a well defined format, while SQLite is not ISO complete.
> > SQLite also has a defined file format. It might not be an ISO standard
> but it is well defined.
>
> 7) A burden to require existing users to obtain and maintain SQLite. Other
> SQLs have their additional administrative overhead.
> > There is no additional administrative overhead (assuming the DBI library
> is included in GnuCash).
>
> 8) XML files are used as long term backup. A conversion risks the
> guarantee that nothing has changed between opening.
> > This is a process question. It is risky to expect your software to never
> change file structure just because the content should be archived for a
> long period of time.
> To archive, the data should be stored in an archive-able format
> (CSV/PDF-A) and maybe also with the software that can read those files
> (although OS might change)
>
> 9) Users who have build their own interfaces to the file will have to
> adapt their custom interfaces
> > These are part of the technical debts if you go down that route.
> Documentation specifically states to not do that. Apart from that, I claim
> that interacting with the file via SQL is a lot easier than XML parsing
> (but that is again just opinion).
>
>
>
> The reason why I am bringing up this topic is exactly, as Derek states:
> Moving into the direction multi-user support. SQLite is not the solution
> but I see it as a step into that direction. Including simplifying the
> complexity.
>
> I would only see point 8 above as a relevant point for XML.
>
> Small step 1 for me would be to allow import/open of XML file but save
> only as SQLite. This would secure GnuCash for the above archiving purposes
> but prepare all future save files as SQLite only. Now we have plenty of
> time to complete the migration away from QOF. If we allow import only (and
> expect a destination working FILE), we might even get around the in-memory
> SQLite DB.
>
> Now we can decide what step 2 is and work on that with less risk/a solid
> base. Maybe parallel SQL and QOF implementation? Or the bit by bit SQL
> migration? Or full QOF replacement.
>
>
> What are your thoughts on that approach?
>
>
> Best wishes,
>
> Stefan
>
>
> ----- Ursprüngliche Mail -----
> Von: "Stefan Bluhm" <gnucash.org at bluhm-de.com>
> An: "gnucash-devel" <gnucash-devel at gnucash.org>
> Gesendet: Montag, 14. September 2020 08:11:09
> Betreff: [GNC-dev] Deprecation of XML file
>
> Hello GnuCash Team,
>
> Is there a reason to keep supporting the XML file in future? Wouldn't it
> be easier to force save the data to SQlite to tackle the move from QOF?
>
> The benefit of point in time save (instead of transactional save) could be
> achieved by working from a copy instead.
>
> Probable issue would arise from users that read the XML file directly.
>
> Let me know your thoughts.
>
> Best wishes,
>
> Stefan
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
David Carlson