Discussion:
PHP/Python (was: RE: Vexim Digest, Vol 68, Issue 4)
Phillip Baker
2010-12-31 08:51:52 UTC
Permalink
All I can say is it is great news and if it no longer needs php for the front end then that is one less hassle set up wise to worry about Terry
Um. Ok, but by far the largest installed base as far as webserver run-time interpreted code is concerned is PHP. For probably 85% of us, we're going to be having to add Python to our webservers instead just to support vexim.

The apparent version portability issues that Avleen has hinted at frankly makes me question if Python is suited to long-lived web applications. The need for an entire framework (Django?) to support a small webapp also makes me squeamish. The whole plan seems to be adding layers of complexity to the supporting software - and each of these layers seems to have known portability issues if Avleen is already having to consider what version of Python he's going to be targeting. Suddenly we have to keep track of Python, Django and Vexim vulnerabilities instead of just Vexim (we already have to track PHP as our customers use it).

I realise that Avleen has to go with what he knows. He (and other contributors) provided us with a great toolset which we've had a lot of use out of over the years for which I am very thankful, but despite its' proponents most fervent wishes, Python has a long way to go before I would consider it normal to encounter in a webserver configuration. On that front, we won't be switching to a Python version; we'll rewrite the PHP version in house if we have to. I don't have time to learn securing a new interpreter in a web environment. The web interface is not so advanced in its functionality that it would take a significant amount of time to rewrite if it did eventually become necessary.

I'm not even trying to change Avleen's mind. What we have in the current version of VExim is more than enough - but I don't want anyone to labour under the illusion that just because they run and think in Python that the majority of us do.

$0.02

Phil
Avleen Vig
2010-12-31 09:52:27 UTC
Permalink
Hi Phil!
Thanks for the very well thought out mail. My reply is in-line :-)
Post by Phillip Baker
All I can say is it is great news and if it no longer needs php for the front end then that is one less hassle set up wise to worry about Terry
Um. Ok, but by far the largest installed base as far as webserver
run-time interpreted code is concerned is PHP. For probably 85% of us,
we're going to be having to add Python to our webservers instead just
to support vexim.
There is certainly no disputing this. You're absolutely right.
Anyone who wants to use Vexim3 will need to install Python and Django.
More below...
Post by Phillip Baker
The apparent version portability issues that Avleen has hinted at
frankly makes me question if Python is suited to long-lived web
applications. The need for an entire framework (Django?) to support a
small webapp also makes me squeamish. The whole plan seems to be
adding layers of complexity to the supporting software - and each of
these layers seems to have known portability issues if Avleen is
already having to consider what version of Python he's going to be
targeting. Suddenly we have to keep track of Python, Django and Vexim
vulnerabilities instead of just Vexim (we already have to track PHP as
our customers use it).
The version portability would exist with PHP also.
For example, there are features of PHP 5.3 which aren't backwards
compatible with 5.1 and 5.2 (which *many* people still have installed as
their only supported or supportable version).

I spent a considerable amount of time testing Smarty, a PHP framework,
to see if that would be suitable and assist in the PHP development line.
Again for the reasons of my own comfort level being able to support and
maintain a PHP app, I had to turn Smarty down.
In any case, I don't think a framework is something to shy away from :-)
It has many advantages for you, the user/admins, as it does for me and
anyone else doing development.
Bugs are arguably easier to find.
Code is simpler (so far Vexim 3 is less than 1/4 the size of Vexim 2).
We get a lot of things "for free", such as more secure authentication.
We actually ended up making a kind of framework with Vexim 2. It was
really messy :-) but it was a framework all the same.

You're right about the vulnerabilities issue. What I can tell you
though is that between them, Python and Django have had far fewer
security vulnerabilities (to the best of my knowledge) than PHP. Python
has been around since the early 90's and is quite stable at this point.

The complexity is a trade-off. There is more complexity in the backend
and framework, yet our code is far simpler which lets us get many more
features out, fix bugs faster, and overall provide a better system.
Post by Phillip Baker
I realise that Avleen has to go with what he knows. He (and other
contributors) provided us with a great toolset which we've had a lot
of use out of over the years for which I am very thankful, but despite
its' proponents most fervent wishes, Python has a long way to go
before I would consider it normal to encounter in a webserver
configuration. On that front, we won't be switching to a Python
version; we'll rewrite the PHP version in house if we have to. I don't
have time to learn securing a new interpreter in a web environment.
The web interface is not so advanced in its functionality that it
would take a significant amount of time to rewrite if it did
eventually become necessary.
The PHP version version certainly isn't "going away".
I'll still be making security updates to it indefinitely. If people need
help with it, help will *always* be provided. No-one will be shut out at
all.
Vexim 3 will be used for new features - someone has expressed interest
already in writing some groupware functionality which would be really
cool.
For what it's worth, I spent 3 years at Google writing applications in
Python + Django. May large organizations run this configuration, just as
many places use Ruby. Both of these are becoming more "normal",
alongside PHP.
As an example, Curse Gaming is a popular website for the computer games
crowd. In 2007 they re-wrote their entire site in Django. At that time
they were serving > 500,000 pages / hour. They're much bigger now.
Woome.com (where I also worked) is an online dating site with many many
millions of users. The entire site is Django too.
Post by Phillip Baker
I'm not even trying to change Avleen's mind. What we have in the
current version of VExim is more than enough - but I don't want anyone
to labour under the illusion that just because they run and think in
Python that the majority of us do.
I completely respect that :-)
As I said, no-one will be "made" to upgrade in any way (I don't have
that control, nor would I want it!). The PHP version will continue to
exist.
If someone want to fork it and take over the open-source development I
would be more than willing to help you do it.
If someone wants to write updates to integrate, say, LDAP
authentication, I will add it to the codebase, test it and release it.

Thanks Phil!
Rimas Kudelis
2010-12-31 10:09:28 UTC
Permalink
Post by Avleen Vig
If someone wants to write updates to integrate, say, LDAP
authentication, I will add it to the codebase, test it and release it.
Have you looked at http://code.google.com/p/vexim/issues/list ? I have
three patches there for you, and they've been there since May...

Rimas
Avleen Vig
2011-01-01 00:12:25 UTC
Permalink
Post by Rimas Kudelis
Post by Avleen Vig
If someone wants to write updates to integrate, say, LDAP
authentication, I will add it to the codebase, test it and release it.
Have you looked at http://code.google.com/p/vexim/issues/list ? I
have three patches there for you, and they've been there since
May...
I'll be getting to those soon :-)
This week has marked the first week I've been able to get back to ciding
Vexim properly in a LONG time!
Rimas Kudelis
2011-02-20 16:01:35 UTC
Permalink
Hi Avleen,
Post by Avleen Vig
Post by Rimas Kudelis
Post by Avleen Vig
If someone wants to write updates to integrate, say, LDAP
authentication, I will add it to the codebase, test it and release it.
Have you looked at http://code.google.com/p/vexim/issues/list ? I
have three patches there for you, and they've been there since
May...
I'll be getting to those soon :-)
This week has marked the first week I've been able to get back to ciding
Vexim properly in a LONG time!
Any news about that? Or did you sober up after the New Year celebration
and go back to your daytime job? :D (no offence intended)

Rimas
Rimas Kudelis
2011-02-21 07:47:07 UTC
Permalink
hah! Hi Rimas!
No offense taken :-)
On fact good news - as part of my job I now have a mandate to
contribute to open source.
The next version is almost ready for public testing.
It's still a ways away from a functional release, but if we can get
some people testing that will help quite a bit.
The current code is up at https://github.com/avleen/vexim
I haven't pushed anything to it in several weeks, but hopefully
tomorrow or tuesday I will be pushing some more changes I've made to
finish getting the siteadmin part ready. The biggest hurdles
1. Get the domain admin parts coded (not started yet)
2. Get groups coded (not started yet)
Hi Avleen,

what about my patches to the PHP version?..

Also, you may want to update Vexim's homepage on silverwraith.com with
the news. It's still frozen in 2007...

Rimas

Phillip Baker
2010-12-31 10:37:50 UTC
Permalink
Post by Avleen Vig
The version portability would exist with PHP also.
For example, there are features of PHP 5.3 which aren't backwards
compatible with 5.1 and 5.2 (which *many* people still have installed as
their only supported or supportable version).
Right. My assumption from what you wrote is that large scale changes take place which means that code written for 2.4 would not function if you have 2.6 installed. It is very seldom in my opinion that subversions of PHP introduce anything so revolutionary that there is a good case to actually use it straight away (causing the backward incompatibility).
Post by Avleen Vig
I spent a considerable amount of time testing Smarty, a PHP framework,
to see if that would be suitable and assist in the PHP development line.
I hate all frameworks. I've tried to play nice with them, but they all seem to be written by people who have their heads screwed on differently to me. My code isn't messy, but I hate MVC with a passion and nearly all the frameworks insist on using it. I prefer useful libraries and functions to entire frameworks.
Post by Avleen Vig
You're right about the vulnerabilities issue. What I can tell you
though is that between them, Python and Django have had far fewer
security vulnerabilities (to the best of my knowledge) than PHP. Python
has been around since the early 90's and is quite stable at this point.
No doubt; PHP does not have a good track record, my point was more that dealing with PHP is well documented and we have a stable and secure setup we use that works for us which I would be hard pressed to move away from.
Post by Avleen Vig
The PHP version version certainly isn't "going away".
I'll still be making security updates to it indefinitely. If people need
help with it, help will *always* be provided. No-one will be shut out at
all.
Well, you'd have to pry the code out of my cold, dead hands for a start :p But it's good to know that it will continue to be supported and maintained. Not that I think there are any skeletons lurking in the closet at this stage, but you never know for sure, especially when you're dealing with a moving target in terms of the version of the interpreter.
Post by Avleen Vig
For what it's worth, I spent 3 years at Google writing applications in
Python + Django. May large organizations run this configuration, just as
many places use Ruby. Both of these are becoming more "normal",
alongside PHP.
There are a great many large sites that use whatever is trendy at the time because the only developer they have at that point likes it and it either shapes the people they employ and they stick with it or they end up switching later (sometimes at great pain). Ruby (on Rails) just makes me ignore a project altogether - it's a nonstarter for me, and I know choosing RoR has killed at least one web startup who subsequently couldn't find any people to come on board to finish the project after their developer got bogged down in other projects. Ultimately organisations have to pick whatever suits their use case and their development team best. Right now IMO nothing is as portable and easy to get going as PHP code. If you're building a single app/site on a dedicated platform however, the rules are
entirely different.
Post by Avleen Vig
Thanks Phil!
Thank you! I hope you have a nice new years, if you're doing anything. Personally, I'm staying in and coding. I think I must be getting old.

Phil
Avleen Vig
2011-01-01 00:11:43 UTC
Permalink
Post by Phillip Baker
Right. My assumption from what you wrote is that large scale changes
take place which means that code written for 2.4 would not function if
you have 2.6 installed. It is very seldom in my opinion that
subversions of PHP introduce anything so revolutionary that there is a
good case to actually use it straight away (causing the backward
incompatibility).
Fortunately it's only broken the other way around (if I use new 2.6
magic in 2.4). But as long as the code tries to stay good to 2.4 (or, at
least 2.5), then it'll mostly work in 2.6, 2.7, etc.
Post by Phillip Baker
Post by Avleen Vig
I spent a considerable amount of time testing Smarty, a PHP framework,
to see if that would be suitable and assist in the PHP development line.
I hate all frameworks. I've tried to play nice with them, but they all
seem to be written by people who have their heads screwed on
differently to me. My code isn't messy, but I hate MVC with a passion
and nearly all the frameworks insist on using it. I prefer useful
libraries and functions to entire frameworks.
:-) Most frameworks (maybe all? at least all the ones I've used..) are
created to bring MVC into the system.
I'm not a huge fan of MVC, and I pretty much hate all ORM's, but to me
Django, RoR, Smarty, etc provide a couple of very useful things:
1. Templating. This can be done without frameworks, but they make it
easier.
2. Separation of code / presentation.
3. Modularisation. I love modularisation :-) It helps a lot with code
maintainability.

All of these can be achieved without frameworks, sure.
But the frameworks have all of this pretty much built in.
MVC took me a *lot* of getting used to. Mostly the Model part. I'm used
to talking directly to the DB myself, from where I want, when I want.
I still don't really like the Model part :-)
That said, I look at the bright side: At least with MVC I can think less
about the database. I'm a systems administrator by trade, not a
programmer, and I advocate doing things the fastest, simplest, laziest
way possible so you can move on to the next thing :-)
Post by Phillip Baker
Post by Avleen Vig
You're right about the vulnerabilities issue. What I can tell you
though is that between them, Python and Django have had far fewer
security vulnerabilities (to the best of my knowledge) than PHP. Python
has been around since the early 90's and is quite stable at this point.
No doubt; PHP does not have a good track record, my point was more
that dealing with PHP is well documented and we have a stable and
secure setup we use that works for us which I would be hard pressed to
move away from.
Absolutely!
Post by Phillip Baker
Post by Avleen Vig
For what it's worth, I spent 3 years at Google writing applications in
Python + Django. May large organizations run this configuration, just as
many places use Ruby. Both of these are becoming more "normal",
alongside PHP.
There are a great many large sites that use whatever is trendy at the
time because the only developer they have at that point likes it and
it either shapes the people they employ and they stick with it or they
end up switching later (sometimes at great pain). Ruby (on Rails) just
makes me ignore a project altogether - it's a nonstarter for me, and I
know choosing RoR has killed at least one web startup who subsequently
couldn't find any people to come on board to finish the project after
their developer got bogged down in other projects. Ultimately
organisations have to pick whatever suits their use case and their
development team best. Right now IMO nothing is as portable and easy
to get going as PHP code. If you're building a single app/site on a
dedicated platform however, the rules are entirely different.
True! I suppose we could say that it's best to use the right tool for
the job. Then we can argue about the job and what the right tool might
be ;)
I'll admit I have a little bit of hammer syndrome - python is my hammer,
and everything looks like a nail. PHP would be a good tool for Vexim 3
if I was *good* at it. But the feature list for v3 is long, and far out
of my ability to implement in PHP.
Post by Phillip Baker
Thank you! I hope you have a nice new years, if you're doing anything.
Personally, I'm staying in and coding. I think I must be getting old.
I'll probably be here coding too ;-)
HAPPY NEW YEAR EVERYONE!
Loading...