shared API for double-entry accounting, treating it as a 'math' library.

[Joar Wandborg]

In the end I think it will be the *API* that should be set in stone, not 
the implementation.

The plan at the moment is to leave the choice of storage in the 
accounting-api reference implementation open. The current development 
version uses ledger-cli although in a flawed manner which means it may 
take several minutes to load the transaction data from disk.

The reference implementation features the following as of this writing:

- A small AngularJS front-end.
- A REST transaction API.
- A REST JSON "de-facto"(it's in the code) format specification.

The current documentation is located at 
http://npoacct.sfconservancy.org/accounting-api/. The code is at 
https://gitorious.org/conservancy/accounting-api/.

The reference implementation and proof-of-concept clients are written in 
order to find out what the *API* should look like. Everything in the 
reference implementation could be subject to change until we have found 
something that works well enough and we may start working on writing the 
specification. If you have criticisms on the way it works today, tell us 
- Preferrably via this mailing list.


On 01/19/2014 12:16 AM, Marc Paré wrote:
> HI Tim,
>
> I was just responding to Daniel's  remarks and nothing else.
>
> Yes, the data will be kept hopefully in sql.
>
> Cheers,
>
> Marc
>
> Le 2014-01-18 07:03, Tim Schofield a écrit :
>  > Hi Marc,
>  >
>  > The data wont be stored in an sql database?
>  > Thanks
>  > Tim
>  >
>  >
>  > On 18 January 2014 11:49, Marc Paré <marc at marcpare.com> wrote:
>  >
>  >     Hi everyone,
>  >
>  >     Yes, I see that I perhaps had not made my point/comment
> completely clear. I was speaking from the point of view of, if any
> specific storage format were to be contemplated, that we at least look
> towards one that had good and solid backing from an open source driven
> organization (in my example, I used the OASIS group). But, sure, we
> could also loop in any report file format(s) that were contemplated as
> well. I am more concerned with any suggestion of adopting a storage file
> format that is not backed by its originating standardization group.
>  >
>  >     Cheers,
>  >
>  >     Marc
>
>