Remove unnecessary configuration - have plugins return unicode?

[petri]

Do I understand correctly that the configuration file is only used to register the character encodings to use with each plugin?

How about just having the plugins return unicode?

If the config file actually registers plugins via mapping of plugin name to python file or something, how about switching to using entry points instead? (see the other issue I submitted)

That way, development of plugins would be decoupled from ofxstatement development, making it easier to contribute.

[kedder]

Do I understand correctly that the configuration file is only used to register the character encodings to use with each plugin?

Not really. It is a general way of configuring plugin, and I'm using other options too in my config file. The reason for that configuration is that several banks I use provide statements in the same format, but that format does not provide enough information to generate a proper OFX file. For example, there is no account number or currency in my CSV statements. Since I have several accounts in these banks, I have to configure each account in configuration file, specifying that missing information.

Basically, this info cannot live in the code, hence the configuration.

Here is a sample of my config file, if that will make more sence:

[dnb]
plugin = litas-esis
charset = cp1257
swap-payee-and-memo = True

[danske:usd]
plugin = litas-esis
charset = cp1257
currency = USD
account = LT12345789012345789012

[danske:ltl]
plugin = litas-esis
charset = cp1257
currency = LTL
account = LT12345789012345789012

How about just having the plugins return unicode?

That encoding is a CSV input encoding, actually, not output encoding. Plugin needs to know how to read the input CSV and convert it to unicode. After CSV is read, all further manipulations are performed on unicode strings.

[petri]

Yes, CSV input encoding is what I meant as well: Given that the banks seldom change the encoding of the CSV that is downloaded, I thought registering and handling input encoding is something naturally delegated to the plugin. You could say I've kind of been considering the encoding part of the format of the CSV. If one would for some reason want to change the encodings of the downloaded files, being able to specify it in configuration would be useful I guess. Or maybe there is some other reason I have not thought of?

Thanks for illustrating the configuration use. Being able to specify multiple accounts, currencies etc. is of course a nice feature. I don't know much about OFX and had not thought about what extra information needs to be there for further applications.

[kedder]

I had this idea: I think it would be useful to make ofxstatement work without configuration file by default, and let users configure plugins if it is necessary in their situation. Character encoding certainly can have a default, and if plugin really cannot live without some configuration value, it can complain loudly about it.

I think it will lower entry barrier a bit.