As an end user I would like to make a few comments/suggestions. The file size is an issue for backup and transfer reasons. Something should be done to control the profileration of .xac and .log files for the users. If the XML format is kept, I suggest adding a backup button which saves a compressed (gzip, zip or some other widely distributed type) to a name given by the user. A companion restore from backup button would be necessary as well. Add a vi type autosave to some format and let the user set the time between autosaves. Clean up autosaved files automatically rather than forcing the user to acquire/write a script to delete old ones. If it was thought neccessary these could be handled like /var/log files keeping one per session/day/week (user choice?) up to five.
On the XML vs binary vs database file. I don't like the binary only option. I do like to be able to get at the data myself using other software when necessary. Thus if a binary format were adopted, there still needs to be a way to export the data to tables (ascii) or an XML file. My preference would be tables (CSV?) and this would seem to be the most natural format since a ledger is a table. There are design issues because of the relational structure and some of the attributes that go with the data as to how this export should be done. In my limited experience with XML I have noticed that it is really not a human readable/writeable format once the number of different tags and the depth of the tree structure gets developed. Currently I would find it much harder to deal with an XML file than tables. With the current version of gnucash my usual procedure for getting at the data is to get it out as html and then strip/replace the tags. I think XML tools are still developer tools and not really for end users. On the other hand text ables can often be imported into other software or massaged with standard utilities such as awk and grep. In principle having an actual database as the storage gives one the ability to extract the data in a variety forms by using the facilities provided with the database. I am not familiar enough with postgres to comment on it. Dale Alspach _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
