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

Re: future of LedgerSMB

Well, here is my sense (not that I am not sure there is a 100% firm concensus).

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.

My understanding of the current concensus is that the core application
and its distribution will remain written in Perl, but with the
appropriate AJAX and XML interfaces, and the common db layer, will be
able to integrate with all sorts of other components fairly
seemlessly.  Perl adds a number of nice features for prototyping (TT
and so forth) which we are intending to use for new/experimental
features where we want to avoid the lava flow effect of XML/XSLT for
the moment.

BTW, I hope this doesn't draw too many flames but every language has
its own maintainability issues.  Jumping from one language to another
because the language is perceived to make code magically more
maintainable is a noop IMO because it is a lot of work to no real
effect.  The better approach is to concentrate on maintainability
within the language itself and allow other add-ons to be written in
whatever other languages people want.  Good coding practices are
always far more important than the language choice (and given the
current state of the code, we have our work cut out for us).

Of course, this also raises another very important cross platform bit.
If you think installing on WIndows is bad when we just have Perl and
a few extensions to support, imagine if you have a custom solution
requiring Python, Ruby, and Java components and are forced to make
sure that all runtimes are working and so forth.

Hope this helps,
Chris Travers

On 1/20/07, Jeff Kowalczyk <..hidden..> wrote:
--- "Joshua D. Drake" <..hidden..> wrote:
> Actually (python) has been discussed. At least two of the core members are
> pro python. Python also gives us a better cross platform capability.

That's interesting to hear. For a long while prior to the LedgerSMB fork, I had
considered working with sql-ledger (i.e. committing to deploying it for
clients) and doing a 1:1 port to python CGI of any SL module I needed to
understand thoroughly, customize, or write tests for, and then run the
module(s) overlaid on the original SL release.

I'm not sure it's actually worth all the effort, but with enough interested
contributors it might make for a good starting point for some of the
refactoring and test retrofitting LedgerSMB has planned. I suppose that could
happen anytime along the development process, on a branch. I'd like to pitch
in, to the extent that I can understand the original perl code.

> That being said, I also don't see any problem with using Perl. The
> problem with perl is not maintainability, it is bad developers. You
> *can* write perfectly maintainable perl code if you choose too.

Right, perl is almost synonymous with CGI applications. If a redesign with
modern web framework and ORM were desired, there are many good options with
Python, especially now.

> In the end, I would expect that it is all irrelevant because we will
> provide an API that allows you to write an interface in anything you want.

Does WSGI have any implementation/traction in the Perl world?
http://search.cpan.org/search?query=WSGI&mode=all returns no results

JSON, YAML and XML-RPC data transfer and automation interfaces as an
alternative to URL query strings would probably open up a lot of integration possibilities.

TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

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
Ledger-smb-devel mailing list