is it possible to save a list of lists in the option db?

[Derek Atkins]

Christian Stimming <stimming@tuhh.de> writes:

> Okay, the reset-to-defaults problem is enough of a bummer to not
> consider the option-db for HBCI data any longer.

As I said, I think this behavior might be a bug...  Part of me is
thinking that the "reset to defaults" button should only reset the
current page instead of the whole option-db.  I'm hoping that Wilddev
and Hampton will pipe in.  If nothing else, it is certainly a bug that
this button resets EVERYTHING including the non-visible options.

> Therefore I'm probably going to store some minimum amount of data in
> the GNCBook kvp-frame, and some more data in the Account kvp-frame.

This is probably a good place to store most of it, although I'm still
thinking that you could (should?) store username/password bindings to
banks in the user's options, not in the book.

> Derek Atkins wrote:
> 
> > There is no way to store lists of strings in the option-db.  You would
> > have to create a new option type to do so.
> 
> 
> No lists at all? I thought that at least plain lists would work
> through the list-option type. But anyway, because of the reset-problem
> I wouldn't want to use even those.

Well, there is a list-of-strings (gnc:make-list-option).  But the list
of values is a static list from which the user makes choices.  In
other words, you have to know (a priori) the list of valid list
entries.  It is not dynamic storage, so not quite what you want.

> *cough* When I'm talking about HBCI support and data that I need to
> store there, I'm really not talking about something that I have made
> up myself :-) . The HBCI specification is quite verbose about which
> different identifications are available and what the relation between
> those is. And if they explicitely specify that multiple user ids can
> be assigned to the same bank accounts, then I better implement that in
> the client application. I mean, it's okay to remind me whether I come
> up with issues that sound stupid^H^H^H^H^H not really well-thought,
> but in this case I've spent the last 3 months on our hbci code in
> http://www.openhbci.de to sort out all these kinds of stuff. (Which is
> why it took so long until I eventually started on gnucash hbci code.)

Well, yes, but think about this in the real world..  Are these
multiple identities going to be used by the same real-world person?  I
can certainly see a bank giving access to an account to me using one
ID and my wife using another.  But I don't see why they would give
_ME_ two identities for the same account.  Hense my pushback of one
identity _per user_ per bank/account.

My wife and I would share the book data (so the bank/account ID
binding should definitely live in the Account KVP), but she would have
her ID and passwords, and I would have mine.

> Most of the HBCI configuration code will be stored in an
> openhbci-owned configuration file anyway. So I will probably let
> gnucash rely on that file with almost any data that I thought gnucash
> might want to store itself.

Ok.

> Christian

-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@MIT.EDU                        PGP key available