Chris, > The core application is probably going to remain in Perl for the > foreseable future and probably far longer. However, we are working on > adding hooks so that additional functionality could be added in other > languages. Rewriting the entire application in Python seems both > unnecessary and time consuming, but that doesn't mean that Python > add-on's cannot be supported.
Hmmm ... I would argue that we'll want to move a whole accounting API into stored procedures before we start supporting 3rd-party add-ons. Once we have the SP's, we can open it up for other people's add-ons with the promise that financial data will be uncompromised. This would also give the OSS world a good example of the value of data-centric vs. middleware-centric application design. In the realm of general structure, I'm uncomfortable with the fact that SMB does not have a GL *table*. While there's nothing innaccurate with doing the P&L on the fly by adding up AR and AP, it's both inefficient and does not provide us with a cross-checking layer in the database which would make data errors easy to detect and resolve. So I'd like to explore adding a GL table to the data model. -- Josh Berkus PostgreSQL @ Sun San Francisco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
