Accounting API considerations

[Joar Wandborg]

Comments encouraged!

==============================
When we have an accounting API
==============================

-----------------------
Alternative 1: Adoption
-----------------------

We convince existing accounting programs to replace their accounting
core with this library.

This enables any third-party applications other than the accounting
application to read and write accounting data via the same accounting
API as is used by the accounting application.

This makes customized analysis or automation of any accounting
transactions very flexible.

Can we provide any more incentives for any existing projects to adopt
the accounting API?

--------------------------------------------------------------------
Alternative 2: Someone creates their own business management APIs on
top of ours
--------------------------------------------------------------------

 - An invoice API that uses the accounting API to store any accounting
transactions. The invoice API handles the invoice management and
stores any transactions related to the invoices via the accounting API.
- The contacts API stores business contact information, such as
shipping addresses, invoicing adresses. The invoice API could then
interface with the contacts API and send out the invoices directly to
the invoicee.

This could create an ecosystem of financial modules that can be arranged
and replaced as wanted. The caveat is that such an ecosystem needs a
community and a community needs tending, "marketing" or "relationship
management" of some sort, healthy growth and momentum.

====================================================
We don't have an accounting API or application - Yet
====================================================

What is an accounting API?

 - Is it the specification of the endpoints, their arguments and
return values?
 - Is it a reference application?
    - Is the reference application the de-facto API specification?
    - Is it a web service?
    - Can you use unix sockets or some lightweight protocol as the
transport?
 - Is it a C-style library?
    - Could it be embedded into compiled binaries? Reference SQLite:
http://sqlite.org/whentouse.html.


-------------------------------------------------------------------
Depending on what the desired output should be, some choices remain
-------------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternative 1: Research, rip out, rename
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Should we research and decide on an existing accounting code base,
then rip it out of it's original project and customize it to fit our need?

Most if not all of the evaluated projects probably have accounting
code somewhere, maybe isolated and independent from and of the
non-accounting code accompanying that code.

The parts that would be left then would be to structure the code in a
fashion that matches our perceptions of what an accounting API-capable
application is.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternative 2: Leverage Ledger
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Should we build on top of a pre-existing codebase?

Ledger as in http://ledger-cli.org is very flexible, basic and uses
simple text files and command line arguments for all operations, it
would be feasible to build an application on top of ledger-cli to
create an accounting API application.

Some caveats:

 - The ledger-cli program uses <8M of heap memory in total on a
minimal balance report run.
 - Unless you use a caching mechanism, most reporting requests that
comes in would require a subprocess of ledger-cli to be spawned.
 - ledger-cli reads a "ledger file" on startup. It cannot as far as I
know load or reload a "ledger file" once started.
 - ledger-cli takes command line arguments in order to produce the
requested reports. This means that ledger-cli will need to be spawned
once for each report unless a caching mechanism is used.

~~~~~~~~~~~~~~~~~~~~~~~
Alternative 3: Reinvent
~~~~~~~~~~~~~~~~~~~~~~~

As there is as far as I know no usable and free-as-in-freedom spinning
wheel that looks like the wheel we need, we might have to reinvent the
wheel using inspiration from other free-spinning wheels and
free-spinning minds on this list.

I suspect that in most cases, building the reference implementation of
the accounting API from scratch would be faster than Alternative 1.
Especially when you can use the source code of our existing projects
for reference. It could give me, and you the developers more control
of the behaviour we would expect.

I'm open for corrections, but building the reference implementation
from scratch, referencing in turn techniques used the existing
projects when needed would be my preferred way.

Still, we haven't got to this choice as of today. We still need to
figure out what exactly our accounting API will be.

-- 
Joar Wandborg
http://wandborg.se