perl OO API?

[Klavs Klavsen <..hidden..>]

Hi guys,

I started a project, called OpenLedger last year, but got a lot of jobs 
as a consultant, which meant I didn't have as much time as I used too - 
and also I got as far in the project that it was usable to me - so had 
to give it a lower priority :(

http://openledger.sourceforge.net/

I would like to work on getting this API to work for LedgerSMB - as I'd 
like to switch to using LedgerSMB, and I currently use this API for two 
things:
1) integration with OSCommerce - via perl scripts that create invoices 
for orders in oscommerce.
2) automaticly (depending on when their subscriptions needs renewal) 
creating invoices for customers and emailing to them as PDF.

My vision with OpenLedger was:
Produce a nice perl-based API, which is to be the ONLY way to
interact with the SL data - no matter if it's the webinterface or some
third-part program that accesses it (and f.ex. python-based programs can
use the perl-based API too  :)

The idea here, is that this would make it easy for other programs to 
integrate with the accounting system - and also clean up the mess that 
is the SQLLedger code (where GUI and business/data handling code is 
totally intertwined).

The openledger project also showed how easy it was to create a SOAP 
interface to the API (there's an example in the openledger CVS).

I would very much like to hear your thoughts and ideas and hope we can 
find some agreement on how you'd like this done - as I would very much 
like there to be a real Free Software Accounting project, with great 
functionality and I'd like to help this along, as it would also help me 
with my own business needs.

I could ofcourse just continue using SQLLedger, with all its security 
bugs (just hide it behind basic auth) - but that's just ugly IMHO.

p.s. I'm open to any object vs. function-based arguments - I'm a fan of 
OO and like the abilities (incl. abstraction) it gives you.

In my opinion, Object-Oriented code, if done right, will enable the API 
to be the same (and thus not forcing projects using it to change their 
code all the time), and being easy to expand using new objects/methods 
and polymorfing functions when an extra parameter is needed for same 
method etc.

--
Regards,
Klavs Klavsen, GSEC, ..hidden.., http://www.EnableIT.dk
Open Source Server, Security and Network Consulting
Phone: +45 364 812 00 Mobile: +45 612 812 00

"Open Source Software - Sometimes you get more than you paid for."