User and system config files

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

> I had been ignoring that warning for quite a long time now, but after
> seeing the backtrace in the logs, it's quite obvious what's causing
> them.  gnc:config-file-format-version doesn't exist anymore.  That
> raises an interesting point...

Hmm, I wonder when that went away?

> These days, I'm especially mindful of forward and backward
> compatibility concerns.  I think we need to think carefully about what
> expectations our users might have about the compatibility of their
> config files.  By allowing the user to supply a guile file to be
> loaded at startup, we're giving them enormous flexibility to change
> the behavior of gnucash.  But, we're also exposing an _enormous_
> public interface -- essentially every guile function and gwrapped
> function or datatype -- an interface that I don't think is so ready to
> be cast in concrete.

I think it's okay -- other applications that expose such a large
interface (e.g. emacs) change that interface over time.  In our case,
the g-wrap functions HAVE been relatively stable.  Also, gnucash never
makes any guarantees about the stability of APIs across "major"
releases (where "major" really means "minor" in the sense that 1.6 ->
1.8 was considered a "major" release).

> I think we have several options.  The simplest is to simple warn users
> that custom guile scripts they write could be broken by even minor
> releases.  Another option is to be more rigid about what data we load
>>From guile config files.  We don't _have_ to execute the user's
> program -- we could just pull out certain config values.  I'm sure
> there are more options.

I think your first option is fine..  We already break configuration
across releases.  For example, changing the name of a report (which
happened with a LOT of reports in SVN vs. 1.8) breaks existing
configurations...  This happened from 1.6 -> 1.8 too.  So, I think
there's precedent for "ignoring" certainly configuration state across
an update.

User-defined scripts IMHO fall under that umbrella.

> What I want to avoid is the sense that we can't change any g-wrapped
> function or guile function just because we're potentially executing
> user scripts that may use any of those.  It's something to think
> about.

*shrugs* I don't think there's ever been any sense that those APIs are
set in stone.  I think we're safe.  If it makes you feel better we can
better document that there are no guarantees on the stability of APIs.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available