[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: future of LedgerSMB


> 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