Here is one possible approach. Software applications allow users to save data in many formats. However, there is the notion of a 'native' format that will support all the features. Users may be given the option to save in other formats, with limited support.
Taking the example of OpenOffice.org Calc, if users choose 'Save As' and select CSV, they see a warning saying that not all formatting and content can be saved in that format. Users have to confirm that they want to go ahead regardless. Following the same model, I believe the 'native' format of GnuCash 2.4 is XML. If users choose to 'Save As' SQLite3, MySQL or PostgreSQL, they may not be able to save all formatting and content. By this approach, it is a win-win for both users and developers. The users get the option to save in relational database formats to use third-party reporting tools and integrate with other applications. And the developers get to bake SQLite3 integration code, for a possible future switch to that format as 'native'. Thanks, Ashok -- View this message in context: http://gnucash.1415818.n4.nabble.com/Getting-2-4-Released-tp2998417p3002926.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
