The ironic thing here is that I was talking about this very idea with a friend who is a python hacker just hours ago. We discussed this exact same thing, implementing something similar to gnumeric. This could allow for a master meta data file which tracks what the other files are and whether certain ranges of data have been externally archived and would have to be imported/ It could also provide the possibility for additional data separation in the future. For example, stock prices could be held in a separate file within the archive, and so could AR/AP lot tracking information. The "nice" thing about this is that the internal file structure could be made to more closely mirror the database back end. Of course, the down side of this is that the simplicity of a single XML schema is lost.
--On Tuesday, April 16, 2002 10:05:17 AM -0700 Josh Sled <[EMAIL PROTECTED]> wrote: > On Mon, Apr 15, 2002 at 10:23:40PM -0400, Michael T. Garrison Stuber > wrote: > >| when her stock reports didn't run properly. While we're on the topic >| where is the metadata that let's GnuCash know that there are other >| files to look at? > > I'm wondering if it's too much for it [the current and old books, and > metadata as necessary] to be a tar/gz file, documented or named as such, > that GNC can access as a VFS? > > My question assumes a certain backend, but I think the current thinking > is to have both the [Postgre]SQL and XML backends. > > ...jsled > > -- > http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo > ${a}@${b}` jabber:[EMAIL PROTECTED], ICQ:4983267, > {AIM,YIM}:joshsled _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
