Re: [Openledger-developer] Random jottings

[Klavs K. <kl...@vs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



on 03/19/05 01:49 Jacques Chester wrote:
| Hello everyone;
|
| Some notes on OpenLedger.
|
Always happy to hear feedback - and even more to receive code ;)

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

To me, those goals are not conflicting.

| 3. Pure SQL-Ledger fork.
|
Pls. define a "pure" SQL-Ledger fork. IMHO it's simply taking the SL
code and rewriting it.
If that is what you mean, that has never been the goal of this project
(in my mind :)
IMHO SL is simply to weaved with the web-gui for it to be fixed.
Therefore I've begun reimplementing the needed features in OpenLedger -
and then anyone can do a SOAP, Web or other interface, which uses the
OpenLedger functions. IMHO SL could be forked into a webinterface ONLY.

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

Indeed it is. Especially if we want to expand the SL functionality (by
enabling modules etc.) we need our own Web interface :)

|
| An intermediate goal would be the creation of a Perl API for
| accounting software.
|
There is no way to make a "general Perl API for for accounting software"
- - every accounting package differs, so it is only possible to write a
Perl API for certain accounting packages.

| 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?
|
Agreed. That's why (as you can see clearly in CVS) I've begun
reimplementing the features, reusing the parts of the code from SL,
which belongs in the API.

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

IMHO in this case, that is a misleading naming policy, as there can be
more than one Business::Ledger. OpenLedger or SL or any other, is not
the only thing in the market - what is now OpenLedger.pm (API to SL
"similar" DB/data) will never support every accounting package on earth
- - and should as such, not be named as if it did.

|
| 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".
|
Currently I only have time to care about the API itself, upon which a
web-gui, CRM/etc. systems integration etc. should happen.

I would be very pleased if you would like to begin implementing a
Web-frontend for the OpenLedger API. We could definetely use it - and
perhaps with a GUI, ready to make use of features in the API -
implementing the needed OpenLedger API features, would go faster :)

- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
~  --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCO+nnPToLeX4GPGIRAnJBAJ9DDsbQz2CyxKrTiX+IMhbqcBbpkgCgj1ch
swDsMe3q5tLFRG8t2vNtSmA=
=X38E
-----END PGP SIGNATURE-----