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. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel