From:	James Mastros	Date:	Tue Aug 10 09:17:36 2004
Subject:	Re: Common features for banking modules

Max Maischein wrote:
> I think that the setup/connection/passwords are also candidates, but the 
> most useful thing would be some kind of common storage to allow various 
> backends (graphing programs, analysis programs, Ebay shipping handlers) 
> access to the banking data. Maybe we could simply come up with some 
> database schema and stuff all transaction rows in there and pull it out 
> again with Class::DBI. Maybe some xSV-file is even better as it doesn't 
> require much technology to access in case of a dramatic failure, and 
> diff and grep work on that too.
On the one hand, I was thinking more in terms of a runtime specification 
then a storage specification -- when you call get_transactions, you get 
back a list of Finance::Bank::Transaction objects, and we specify how a 
Finance::Bank::Transaction object behaves.

On the other hand, I was also seeing specification of the transaction 
objects as a very good place to begin, and the place that's most 
interesting.

I'll write up my notes on F::B::Norisbank's transaction hashref (not 
blessed in the current version) as a sepperate post.

> The transaction details are a tricky thing, but possibly, there are some 
> "standards", at least for Germany. I'd like a separate set of parsers 
> for that, as then the applications could recycle the work done there.
I was thinking that those parsers would end up in the standard 
Finance::Bank::Transaction module.  It may be a better idea not to, 
though, as they're likely to vary quite a bit, and it makes little sense 
to run parsers that you know won't work -- the parser for transactions 
against visa debit cards from Germany is unlikely to work against 
savings accounts in the US, so there's no point in trying it.

	-=- James Mastros