From:	James Mastros	Date:	Tue Aug  3 03:02:46 2004
Subject:	Getting started

Hello, everybody,
   Welcome to finance-bank.  This is a first-things-first post, so first 
off, I'd like everybody to introduce themselves.  I'm James Mastros, and 
my module is Finance-Bank-Norisbank, for customers of Norisbank AG, of 
Germany.  If you live in Germany, I bet you've gotten their obnoxious 
"EasyCredit" junk mail -- but it turns out that they have a very 
informative, but highly obnoxious, online banking system.  The code is 
pretty custom -- I didn't base my code on one of the other 
Finance-Bank-* modules, meaning my API isn't influenced by them.
   I found while doing research before starting this list that many of 
the Finance-Bank-* modules are based upon each-other.  This means that 
there actually is some API compatibility, but it's all organic, meaning 
both that there's no central documentation of the commonalities, that 
you can't rely on their being commonalities, and that it doesn't 
neccessarly all make much sense.
   I think the first thing we need to decide is if we want to start by 
finding the commonalities between most of the FB* modules, and working 
that into a specification, or if we want to try to create a sensible 
standard, and work toward adopting it in later versions of our modules, 
and dropping or obsoleting our old APIs.
   I'd rather do the later, not because it's less work for me, but 
because I think, while it's /more/ work for everybody, it'll produce a 
much better result.
   For example, most modules seem to have a check_balance method, that 
returns an account object.  We could simply specify that modules should 
have a check_balance method, that returns an account object.  That'd be 
easy, but it wouldn't be as sensible as naming the method something that 
actually made sense.
   Or, we can start by specifying the holes -- for example, no module 
(that I've looked at) gives a good specification on how to get 
transaction details, and the meaning of the details that you get (which 
I consider to be the most important part of a FB* module).  That way we 
can get something done before we end up fracturing into flame wars and 
long arguments (aren't I optimistic!)... but if we don't get any further 
then that, users will still need sepperate driver code for our modules, 
which is decidedly non-optimal.

	-=- James Mastros