price-db storage via BackEnd?

[Dave Peticolas]

On 21 May 2001 13:31:07 -0500, Rob Browning wrote:
> linas@linas.org (Linas Vepstas) writes:
> 
> > dimwit question: are you sure you want to make your configs global?
> > It seems it might be nice to have different configs on different
> > machines ...
> 
> I've discussed this with Bill and Dave at various points, and I think
> the upshot is that in the long run, some options need to be per
> machine (i.e. per-user per-machine -- in ~/*), and some need to be
> per-user per-data file, i.e. stored in the data file per-user.

That wasn't the upshot I remember :) I don't think we ever really
reached agreement on this issue.


> There are several reasons for this, not the least of which is that as
> we store more and more complex "report setups", a user accessing the
> same data file from home and from work would expect their complex
> report configurations to show up both places, and further, as this
> per-user data gets to be a more substantial amount of information, you
> don't want to end up with a monotonically increasing size for the
> user's home directory.  i.e. unless this data is stored in the data
> file, when you delete the data file, the corresponding (useless)
> config data will remain in the users ~/.gnucash/ directory until the
> end of time.  (Bad behavior IMO.)

I think the "automatically delete configuration when you delete
the data file" problem is a red herring. It really wouldn't be
hard to write a script to go through all the files in the config
directory and remove the ones that refer to non-existant files.
Do that when you start gnucash & problem solved.


> So data that's file-specific should go in the file, and data that's
> machine specific should go in the user's home directory.  Right now
> we're not doing that, but IMO we should be.  However, to do it
> completely right may require "fixing" other people's infrastructure
> like Gnome MDI.  As it stands, MDI stores the document config info you
> give it (and it's config info) in your home directory, even though
> that info may only apply to a given data file (in our case, a given
> .gnc file).  With this arrangement, when you delete that file, Gnome
> MDI has no way of knowing about it, and so the data will just stay
> around forever -- not a scalable approach, really.

Again, it would be easy to scan the Gnome MDI configurations and
remove the sections for non-existant files. I think you are making
a mountain out of a molehill here.

I have several problems with storing configuration data in the
data file. First, configuration data is generally treated differently
than "real" data in applications. Configuration data is generally
saved automatically when you exit, and sometimes whenever you make
a change. That means saving configuration data should be relatively
fast. Storing it in the XML file means you have to save everything
just to save the config data.

My second, bigger problem, is that configuration data is user-specific
and that means machine-specific. User X on machine Y isn't necessarily
the same person as User X on machine Z. It seems to me that if we start
adding user configuration to the data file, we have to implement our own
user-identification system and use that instead of the machine-specific
one. And maybe for real multi-user setups this is what you have to do.
But for standard, single-user gnucash this seems like a burden.

One thing that might be useful is to separate the content of
the main window configuration (the reports & their options), from the
user-specific choices about which ones to view. The reports could be
stored with the data file (either in it or in an adjacent file) and
the user-specific choices about which ones to view & how to place
them in windows would be stored in the home directory. This would
allow other people to load instantiated-reports created by other
users. Quicken has (or had) something similar called "memorized
reports" where you could add an instatiated report to the menus.

dave