No file or file required ?

[Geert Janssens]

I am about to close https://bugzilla.gnome.org/show_bug.cgi?id=479581 as it is 
fairly trivial.

I think the bug is still open because of the log archive it links to:
http://lists.gnucash.org/logs/2007/09/2007-09-26.html#T18:37:32

In short Derek would like to see that GnuCash can never be running in a state 
where it has "no file" to back it. In the current context, a "file" means an 
xml file, an sqlite file or a mysql or postgres db.

For me this is a separate issue from bug 479581, which I think should be 
discussed a little further. That's why I started this thread, instead of 
simply writing a new bug report.

First things first: I assume Derek's suggestion is comes based on the risk of 
potential data loss when no "file" is available, yet the user can go and play 
with all of GnuCash' features.

"Enforcing" a "file" to be selected from the start, or disallowing any action 
if no "file" is available is one way to deal with this. In case of a db "file" 
or an sqlite "file", all changes are written to the backend immediately, for 
the xml "file" a separate log is kept to which all changes are written 
immediately as well. So indeed, having a file available at all times helps to 
prevent data loss.

Enforcing this internally is one thing, enforcing it on the user however is 
another. See, users are accustomed to the paradigm that you can open a 
program, create a new file (without deciding where to store it) play with it, 
and only THEN decide whether or not and where to store the file.

Requiring a user to enter a storage location beforehand is counter-intuitive 
in this context.

But I think these two perspectives aren't necesarily mutually exclusive. 
OpenOffice.org deals with this situation rather nicely: should the program 
crash before you can save your changes, you are offered to recover your 
changes on the next launch of OOo. So internally OOo has saved the changes 
somewhere. This location is not revealed to the user (who doesn't care about 
that either), but this saved information can be recalled anyway by the program 
as needed.

So for GnuCash this could translate as: allow the user to have unsaved data 
(start with option --nofile or as a result of the first run). In this case, 
GnuCash should save the changes to a file anyway in a location that is 
determined a build time (likely somewhere in a tmp directory). This log can be 
in the old xml log format, but when sqlite becomes the new default file 
format, making the GnuCash internal log file an sqlite file would make more 
sense. Should GnuCash have to recover from a crash, it could use this internal 
log for that purpose.

What do others think ?

Geert

P.S. Although I started this discussion, I'm not sure I will be the one to 
implement all this, given I don't have the experience (yet). But I would like 
to come to a clean design spec anyway as I didn't want Derek's suggestion to 
go lost an because a clean design spec will make it easier to implement 
finally, by whoever it will be.