[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking beyond 1.3: Kernalization and requirements proposals.
- Subject: Re: Looking beyond 1.3: Kernalization and requirements proposals.
- From: Chris Travers <..hidden..>
- Date: Sun, 7 Mar 2010 12:15:25 -0800
On Sun, Mar 7, 2010 at 11:49 AM, David A. Bandel <..hidden..> wrote:
> On Sat, Mar 6, 2010 at 13:56, Luke <..hidden..> wrote:
>
>>
>> Can the codebase be moved to PHP while you're at it?;-) (A guy can dream,
>> even if unrealistically)
>>
>
> I would hope this would never happen. I have strings of horror
> stories related to PHP and do not and will not ever install this
> security disaster on an accouting server. I get a sinking feeling
> every time PHP comes up.
>
> Any modules or other pieces written in PHP I feel I need would have to
> be rewritten in Perl.
There are a couple reasons why I would be extremely surprised if the
LedgerSMB core team ever decided to move to PHP as the primary
implementation. None of them have to do with the complexity of
administration or general glut of low-quality PHP-programs out there
(both of which are real issues). I could see some folks pushing for
Python, but I doubt that will happen either for reasons of inertia.
The major issue is that PHP is really designed fundamentally to be a
quick and easy preprocessor for SGML documents. For this area it does
OK although administration can be complex at times. The biggest issue
is that PHP breaks down the further you move out of this environment.
Moving to PHP would add some burdens on administrators, but would also
more importantly lock us into a web-app (and maybe web-service) only
model for the software. Yes, I am aware there are modules for PHP
that purport to give GUI functionality, etc. but these are a LOT more
klunky than Perl variants and none of them have really taken off.
When was the last time anyone on this list actually used a GUI program
written in PHP?
It would be really nice to have a solid chunk of code that could be
used for web application and thick client versions all together. PHP
doesn't do that well. Perl is a much better choice. Python is
arguably reasonable though GUI options on Windows (assuming we want to
distribute a complete solution as an installer) are much more limited.
Best Wishes,
Chris Travers