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

Re: future of LedgerSMB



We have something to gain.

If we rewrite the entire application at once, I am quite afraid it
will never be completed simply because it is such a big task.
Rewriting in Perl gives us the ability to have a useful application
while we are working on it.  I am sure after 2.0, there may be some
cause to re-evaluate this.  But we will have to see then how much code
there is in the V and C layers (which almost by definition cannot go
in the db).

On 1/21/07, Joshua D. Drake <..hidden..> wrote:


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

That is what the current plan is :)

Ok, to clarify-- allowing third party add-ons, providing some
directional support, etc. happens today.  However, these are somewhat
limited in scope by the factors described above.  I would expect this
to be something other than an all-or-nothing situation where such
add-ons become more practical as we go forward but do so gradually.  I
think until 2.0 the line is likely to be "these will be supported at
some point in the future" but I suppose this only tells half the
story.  To the extent that it is feasible (and perhaps even beyond
that point), I am sure that the community will do it....


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

It is on my list to re-evaluate the *entire* model.

I think we all are looking at the current model as fundamentally
broken.  (Anyone disagree?).

Best WIshes,
Chris Travers