[Openledger-developer] Random jottings

[Jacques C. <ja...@ch...>]

Hello everyone;



Some notes on OpenLedger.


A: Project aims.

Seem to be several, partly incompatible goals:

1. Improve SQL-Ledger development process and culture;
2. Separate SQL-Ledger frontend and backend code;
3. Create new Perl accounting API, using SQL-Ledger as backend, or as
supply of snippets for backend;
4. Create new accounting applications.

I would suggest that a final endgoal should be adopted. Is it:

1. A fully realised accounting suite - complete with front end
implementation,
2. Backend modules for Perl, for accounting purposes, or
3. Pure SQL-Ledger fork.

I suggest that your long term goal would be the full suite,
probably implemented as  a website and maybe in other forms for
interested parties.

An intermediate goal would be the creation of a Perl API for
accounting software.

I'm uncertain that purely forking SQL-Ledger code will be
successful; you carry a lot of complexity across. Should an API
map to SQL-L objects directly, or indirectly?

B: On names and namespace issues

I would say that "OpenLedger" would be used to name the project 
generally, and perhaps any complete "turnkey" suite produced
in future.

I would suggest that as an aid to understanding, backend Perl
modules should not keep the OpenLedger name. I saw
Business::Ledger and Business::Accounting suggested. These
would fit with the subject-function naming convention common to
many CPAN modules.

C: On not reinventing wheels.

It's customary in the early stages of new projects for everyone
to spruik their favourite pet technology. Since I am a stickler
for tradition, I would suggest that development take place using
Chris Winter's OpenInteract2 perl application framework.

OI2, which is nearly its point-oh release, is a heavyweight
framework for perl applications, with a particular emphasis on
web applications.

The framework includes "free" logging, template support (for
multiple templating engines), url-to-action resolution, a
full MVC design pattern, CPAN-distributable plugins and
applications, database persistance (included limited SQL
abstraction), per-object security, and so much other neat stuff
that my head hurts thinking about. Essentially it takes a lot of
the useless grunt work out of writing perl applications. I've been
tinkering with it a little, but I'll admit I'm no code god.

It's been used for a few perl apps, but most of the work
has been trivial example programs. I bet Chris would leap at
the chance to help out on a more ambitious project to really
put the system through its paces.

Chris does most of the work on his own and is very, very
well organised. He's written pages and pages of documentation,
discusses his design decisions at length, and meticulously logs
bugs and feature requests.

http://www.openinteract.org/

The downside, as I intimated above, is that the framework is
"heavyweight".


That's enough from me.

JC.