[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Choosing which Ledger to use?
- Subject: Re: Choosing which Ledger to use?
- From: Luke <..hidden..>
- Date: Sun, 30 Jan 2011 19:06:34 -0500 (EST)
On Sun, 30 Jan 2011, Lyle wrote:
On 30/01/2011 19:44, Chris Travers wrote:
On Sun, Jan 30, 2011 at 11:41 AM, Lyle<..hidden..> wrote:
On 30/01/2011 19:17, Chris Travers wrote:
In 1.3, we are using CGI::Simple and use strict for new code. I
expect these to be used in 2.0 as well. I'd like to be able to add
compatibility classes for Catalyst and others if necessary.
Catalyst is a major pain, it adds needless complexity, quickly creates
dependency hell, and you can say goodbye to running smoothly through
CGI. Had to work on it with one of my part time contracts, not a fan at
all. I'm not sure exactly what you mean by compatibility class but
putting LedgerSMB onto Catalyst would be a mistake.
I'm inclined to agree with you on this, actually. The question is for
those who WANT to run it on Catalyst should we provide some method of
support? I don't think we have enough information to answer that at
this time, but I'd like to leave open the possibility.
The only way I can think of doing this would be to make everything
modular (if it's not already) and separate all the web UI stuff from all
the data methods and functionality. That way they could choose to put
whatever front on it they wanted. You could also define a clear API as
an alternative to the template based web UI, that way any Perl framework
or other piece of software in any language for that matter could provide
a front for Ledger. Seems to be the way a lot of applications are going
What I said!:-) I was pushing for that back when 2.0 was first being
discussed. I'm blind, and also do a non-trivial percentage of work with
mobile platforms. The two of those lead me to a lot of weird interface
concerns, that the average mozilla user isn't going to hit. It has caused
me to have a certain lack of desire to be locked into a single interface.
So I wanted there to be a server side API, and all clients talking to
that, including a web service client, which would then serve web clients,
which would probably be running on the same server as the server side
Maybe interact through XML exchange or the like, to keep it stateless.
these days. I've even seen some do away with most of the server side
interacting with the API...
Now that's just scary.