price-db storage via BackEnd?

[Rob Browning]

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.

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.)

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.

One solution would be for Gnome MDI to have an API that allows you to
tell it to give you the data it wants stored, and to ask you for that
data when it needs it (i.e. at file open time).  That seems like a
much cleaner approach for situations like ours.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930