Front page | perl.finance.bank |
Postings from August 2004
From: James Mastros
August 3, 2004 02:02
Message ID: email@example.com
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
by James Mastros