price-db storage via BackEnd?

[Rob Browning]

Dave Peticolas <dave@krondo.com> writes:

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

OK.  Sorry for putting words in your mouth.
 
> 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.

This seems really dangerous.  What if the volume in question isn't
mounted?  What if the user has just "mv'ed" the file?

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

Maybe so, but it sure doesn't seem that way to me.

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

To me, this is just an implementation detail, there's no reason we
can't have a more DB like backend.  Even with XML, we could fix it up
to have fast sectional re-writes, especially now that Jim has migrated
us to be able to generate the tree piecemeal.

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

This is a good point, an excellent point, actually, that I wasn't
thinking of, but as you mention, in a real multi-user setup, we'll
*have* to handle this.  Though I don't think it has to be too much a
burden if you have reasonable defaults.  For example, ssh presumes
you're the same user on the remote end unless you say otherwise.

Also, this problem is already popping up with the people doing the web
work with the SQL backend.  Unless we put the config data in the data
store, they're just going to have to re-invent the wheel as far as
config data that ought to be common is concerned.

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

In the long run, though, whether the Backend uses one file or many
should be as transparent as possible to the app IMO.

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

Well, if I were using rsync or vpn+NFS to allow me to work on the same
file from work and home, I'd probably want my changes to automatically
show up both places, wrt to reports *and* window config, and this is
one place, that unless we go to some lengths, the on-line web-based,
server-hosted financial apps/services (including things like
"MyFidelity", etc.) will do things "more correctly" without any extra
infrastructure.

FWIW

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