Fwd: Re: Accounting API considerations

[Joar Wandborg]

Forwarding this reply from Chris Travers that missed the list.

-------- Original Message --------
Subject: Re: Accounting API considerations
Date: Wed, 4 Dec 2013 01:22:43 -0800
From: Chris Travers <chris.travers at gmail.com>
To: Joar Wandborg <joar at wandborg.se>

On Dec 3, 2013 11:41 PM, "Joar Wandborg" <joar at wandborg.se> wrote:
>
> Comments encouraged!
>
> ==============================
> When we have an accounting API
> ==============================
>
> -----------------------
> Alternative 1: Adoption
> -----------------------
>
> We convince existing accounting programs to replace their accounting
> core with this library.

I would be slightly wary of this because many such programs do a great deal
more than accounting so this ends up requiring some sort of direct access
to underlying data preferably though a relational API.

However I dont think this totally invalidates this work.  If you had a
reference implementation and spec then programs on both sides of the API
could be replaced with compatible ones and that could offer smooth upgrade
paths.
>
> 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.

Yes and if it was well specified it would also allow other accounting
engines to be used where other features beyond what might be initially
contemplated are needed.  Future versions could then expand this common
subset as well.
>
> 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?

Form the perspective of LSMB we would want to make sure that our ability to
write advances reports tying financial and nonfinancial data would not be
affected.  For example for or for profit users, running a PNL report on a
product over time. I suspect we would be more likely to offer a compatible
interface than just use the library.
>
> --------------------------------------------------------------------
> 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.
>

+1. But this is not incompatible with the above.  Don't underestimate the
power of a reference implementation in a production environment.
> ====================================================
> 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?

Personally I would favor a reference application with a formal
specification.

>     - 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?

I think you want it to be transport neutral. This is where command line
apps as a library of functionality really shine.

If I were doing this right now I would at least consider some way of just
supporting stdin and stdout. If someone wants to wrap that in a web service
that would then be trivial.  It also makes tests a bit easier.

>  - Is it a C-style library?
>     - Could it be embedded into compiled binaries?

Why not?
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.

Almost any system is going to require frequent respawning of processes or
at least threads for concurrent reports. The larger question I have there
is whether it reads all info on every report.  If so you will have issues
scaling to larger data sets.  This is not fatal to a reference
implementation and if it is the case it would just mean your reference
implementation would be limited to smaller NPOs. It would seem ok to expect
other projects to make things work in a compatible way.
>
> ~~~~~~~~~~~~~~~~~~~~~~~
> 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.

If the work was being done as a db extensiom in Postgres, I would be happy
to contribute code from where we are going with our own rewrite. I am
particularly open to BSD and GPL v2 licences but could likely find ways of
working with almost all other Free Software licenses.
>
> 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
> _______________________________________________
> npo-accounting mailing list
> npo-accounting at sfconservancy.org
> http://lists.sfconservancy.org/mailman/listinfo/npo-accounting