till wrote:

Hi,

we were just pondering how many of you still rely on PHP4 support since we'd make life easier and drop it on devel-vnext completely. Same goes for our DB logic, MDB2 is very mature currently - should we rely on it exclusively?

Thoughts? Comments? Feedback?

All my environments are still running php4 and won't be upgraded soon (Since I don't see a compelling reason, from a user's point of view).

Regards, Ben

Till et. al:

I personally try to run php4 and php5 concurrently. I rely upon php4 as my main interpreter, and those scripts denoted with an extension of ".php5" will be interpreted by php5.

I'd love to see Roundcube move to php5; however, I think it should come at a time when php5 is more widely adopted. Most hosts now run php4, with an option to use php5. PHP5 is rarely offered as the only PHP.

If anyone needs help running php4 and php5 concurrently in a Windows environment, you can read my sticky post over at: http://phpbuilder.com/board/ in the "Install" section.

~Brett

till wrote:

Hi,

we were just pondering how many of you still rely on PHP4 support since we'd make life easier and drop it on devel-vnext completely. Same goes for our DB logic, MDB2 is very mature currently - should we rely on it exclusively?

Thoughts? Comments? Feedback?

Cheers, Till

PHP 5 only here, I have no strong feelings about MDB2

Because most shared hosts can't upgrade their php because they're reselling resold space. So until the owner of the server upgrades it, they'll be using php4. I've heard many admins say there's no difference between the two, but I prefer php5 over php4. But I still like to have that compatability (which is why I run them concurrently).

It's kind of the same reason people don't use Apache 2.0 as much.
1.3.37 is still very stable and good, but there are improvements in 2.0. But because the reseller can't upgrade apache because he's not a root user, they use 1.3.37 and the owner sees no need to upgrade.

I personally think we'll see php5 start to crop up more as php6 gets closer and closer into release. It wouldn't surprise me at all if some hosts jump directly from php4 to php6.

~Brett

till wrote:

Not to single you out - but in general.

Can people elaborate why PHP4 is their only option. Trying to get the big picture. :-)

On 6/18/07, Pablo Manuel Rizzo info@pablorizzo.com wrote:

...

PHP4 here!

-- Pablo Manuel Rizzo

---

Aunque supiera que el mundo se acabará mañana, Igual plantaría mi manzano. -- Martin Luther King --

---

On 6/18/07, Brett Patterson brett@bpatterson.net wrote:

Because most shared hosts can't upgrade their php because they're reselling resold space. So until the owner of the server upgrades it, they'll be using php4. I've heard many admins say there's no difference between the two, but I prefer php5 over php4. But I still like to have that compatability (which is why I run them concurrently).

Personally - I primarily run it in regard to clients who use "old scripts" which may not work with PHP5, but all in all I am not the greatest PHP coder in the world and all my stuff done on PHP4 worked without any stress on PHP5.

The bigger issues still are register_globals and the like. ;-(

I do like PHP5 for its OOP features - abstract classes, protected/private/static, (real) singletons, build in SOAP, exceptions, overall clean code and so on. PDO is also something worth looking into. And there's so much more - so forgive me if I forgot your most favorite feature. :-)

I also found it more speedy, there's been improvents in the core with are noteworthy.

Last but not least - there are frameworks which I use, which make live a lot easier. Also, starting January 1st this year, PEAR has a policy where it only accepts PHP5-compliant packages (E_STRICT and so on) into the repository which for me cranks up the need since I like to use them.

In general I also wonder - do distros keep their PHP4 also up to date? I remember last time I had to work Fedora Core and those yummy RPMs - it was a pain to find PHP4 packages where PHP5 was all over the place.

It's kind of the same reason people don't use Apache 2.0 as much. 1.3.37 is still very stable and good, but there are improvements in 2.0. But because the reseller can't upgrade apache because he's not a root user, they use 1.3.37 and the owner sees no need to upgrade.

I primarily run that 1.3.x myself (together with PHP5, of course :D) because I know how to tweak it. Apache2 - well I don't want to flame it, but I have yet to see a reason to upgrade. I also adore the stability of the 1.3 branch. I have clients that run Apache2 exclusively and they are really a bi... to take care of. So demanding. Whereas many 1.3.x's just sit there and take the big hits day after day.

I personally think we'll see php5 start to crop up more as php6 gets closer and closer into release. It wouldn't surprise me at all if some hosts jump directly from php4 to php6.

Yeah, I agree. ;-( Though code that worked on php4>php5 will probably not work as well on php6 - if you never bothered before that.

Cheers, Till

On 6/18/07, Brett Patterson brett@bpatterson.net wrote:

I don't know. Apache 2 to me is much easier to tweak and modify. Probably because it's much more modular. I mean they finally took a bulk of the conf stuff out of the main file, and made them includes!! Finally!! But I've been running 2.0 (well, 2.2) since it's come out, and not once has it failed on me (without my own intervention). Right now it's just a preference thing. But I can't see Apache 1 being developed past 1.4 (if that).

Funny, I always liked the one include file and a 100 includes (and essentially file handles) are a "no go" - imHo. ;-)) Always interesting how different those kind of things are perceived from the "community".

I am on my way to lighttpd - where time permits. :-)

...

In general I also wonder - do distros keep their PHP4 also up to date?

I don't use Linux (except for hosting) so I don't get to play much with RPMs and packages. But I can say that it's much better to compile it from source since each system is slightly different. So I've never put time into actually installing an RPM version of php, I've always compiled from source.

You would probably love FreeBSD's ports - builds from source. Or portage on Gentoo. :-)

Till

Oops! I did not intend to send this from the list administrators alias. Obviously the below are my personal opinions, and nothing more! Sorry!

Bob

RoundCube Mailing List Administrators wrote:

till wrote:

...

we were just pondering how many of you still rely on PHP4 support since we'd make life easier and drop it on devel-vnext completely. Same goes for our DB logic, MDB2 is very mature currently

Well, it seems the battle for PHP5 is lost once again. For what it's worth, I'd be in favor of moving a NG branch to PHP5 only, but there seems to be no consensus on the list. Also if I remember correctly, Thomas was against the idea the last time it came up...

Should you decide to go in that direction (either now or at a later time) I'd personally prefer that PDO was used over MDB2, but then again I'm not the one writing the code :-)

Hi,

we were just pondering how many of you still rely on PHP4 support since we'd make life easier and drop it on devel-vnext completely. Same goes for our DB logic, MDB2 is very mature currently - should we rely on it exclusively?

Thoughts? Comments? Feedback?

Hi everyone.. I haven't posted before, I just have a few lists that I follow the dev discussion on for a few reasons, and this is one of them. I'm also on the squirrelmail-dev list, and right now the same discussion is going on. It started with a post by a developer of the Drupal project and has gone from there. I encourage everyone interested to read through that thread as they explore this idea in some more detail:

http://thread.gmane.org/gmane.mail.squirrelmail.devel/8644

I personally think it's a good idea to move forward and use PHP5. Really, the main reason PHP5 apps aren't being built is just because of that one thing that people are mentioning, their host doesn't have it installed. But if they had an incentive to upgrade, they would. I personally think this mentality is hindering progress, but I also respect others' viewpoints on the matter. The move to apache2 has been compared, and I think that's another example where the move should be done. It has support for threading, so when a new request comes in, an entire server process doesn't have to be forked! What a tremendous potential resource savings if all hosts were to just switch... That's just one example, there are lots more..

Regards,

• Matt

Matt Barnicle wrote:

...

Hi,

we were just pondering how many of you still rely on PHP4 support since we'd make life easier and drop it on devel-vnext completely. Same goes for our DB logic, MDB2 is very mature currently - should we rely on it exclusively?

Thoughts? Comments? Feedback?

I personally think it's a good idea to move forward and use PHP5. Really, the main reason PHP5 apps aren't being built is just because of that one thing that people are mentioning, their host doesn't have it installed. But if they had an incentive to upgrade, they would.

I partly agree with you here, that's what I was talking about when I said that PHP5 doesn't have the "killer-apps" that make me upgrade. Currently I don't care for PHP5. Why should I? And until some brave projects drop PHP4 support and are really interesting for me I won't make the switch. Does this stop progress? No idea, I don't care for new versions of PHP and wouldn't know the difference, probably. As long as something presents me a nice webmail interface I cannot guess if it runs on perl, ruby, php or java (we ignore 'standard' file extensions for now). It's not that I'm not a technical person. In fact I even earn my money as a software developer (not web development though), but I care for PHP4 or 5 under RCs hood as much as for the origin of my cars parts. As long as it works its fine for me. No need to change anything.

I personally think this mentality is hindering progress, but I also respect others' viewpoints on the matter. The move to apache2 has been compared, and I think that's another example where the move should be done. It has support for threading, so when a new request comes in, an entire server process doesn't have to be forked! What a tremendous potential resource savings if all hosts were to just switch... That's just one example, there are lots more..

This is something that I wouldn't want to sign. With threading come problems (a looong time several PHP extensions weren't even threadsafe) and if you look at the other (completely OT, yes) webserver related posts above in this thread you'll notice that quite some people (me included) switched away from apache to for example lighttpd. Which - incidently - is a single process. Yes, only one. That doesn't say that it's not fast. The contrary is quite true. I don't want to troll here, but these conclusions of yours are a little bit off..

Regards, Ben

On 6/18/07, Brian Jackson iggy@theiggy.com wrote:

If roundcube did switch to requiring mdb2, I have a local patch that uses mdb2's xml schema stuff to automatically install and maintain the database table layout.

Very cool, maybe you want to open a ticket on the trac?

Cheers, Till

The move to apache2 has been compared, and I think that's another example where the move should be done.
It has support for threading, so when a new request comes in, an entire server process
doesn't have to be forked! What a tremendous potential resource savings if all hosts
were to just switch...

I sent this to a co-worker in March of last year -

. . . Windows likes to use threads within processes rather than
additional processes. That is a design decision. UNIX systems can create and destroy
processes very quickly, while creating and destroying threads on
UNIX systems takes longer. Windows is the opposite, threads are
fast to create/destroy. That is the main reason apache2 has
different MPMs. One optimized for UNIX-style systems, and one for
Windows. The problem with that is now programmers can go hog wild
and create MPMs for no apparent reason besides the fact that they
can ;) It gets confusing.

That's why the big warning about PHP and apache2. Because you can
run a threaded MPM, there are some libraries that PHP links to that
don't understand threads, even if PHP does. If you use a process- based MPM with apache2, then you won't get data synchronization
issues while using PHP.

The threaded MPM is only an advantage on Windows, it isn't a
_universal_ advantage.

I read through the SM thread. At some point, PHP4 will not be
updated, so a transition to PHP5 _will_ be required. The question is,
does RoundCube choose how and when the transition happens, or allow
external forces ( PHP developers ) to dictate the timeline ?

I understand that RoundCube currently can run on PHP5, although I
have not done so myself. To encourage PHP5 use, why not list it in
the requirements as "will run using PHP5" or "tested using PHP5"

The 5/2/2008 date seems to be as good as any to pick. If a PHP4- compatible release is made some time before the transition date, then
users forced to use PHP4 can use that older release. If there remains
a large PHP4 user base, security changes could be back-ported to that
PHP4-compatible RoundCube release. If the PHP4 user base isn't
interested in doing the work to back port those security updates,
then there isn't much use for it.

Code changes that are security only would have to be announced, so
that those that do the back porting know there is work to be done.

Maybe version 1.0 of RoundCube is the last PHP4-compatible release ?

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

I haven't so far because I didn't have a good solution for the older
db library other than just say forget it. I didn't think that would
go over very well, but if mdb2 becomes the only db library, I'd be
more than happy to resurrect the patch and port it to latest svn. I
may have even had at one point a patch to rip out the older db
library and leave all the db access parts connected directly to mdb2,
but I'd have to dig a lot for that.

--Brian Jackson

On Jun 18, 2007, at 5:11 PM, till wrote:

On 6/18/07, Brian Jackson iggy@theiggy.com wrote:

...

If roundcube did switch to requiring mdb2, I have a local patch that uses mdb2's xml schema stuff to automatically install and maintain the database table layout.

Very cool, maybe you want to open a ticket on the trac?

Cheers, Till

As said by others, there does need to be a reason for PHP5 change. Is
there any proposed code that requires PHP5, probably not. My vision would be that RC changes to PHP5 in a major release eg.
Roundcube 2. There would be little point swapping to PHP5 without re-doing classes
using the new OOP features, implementing exception catching etc. (taking
advantage of it). Also a coding guide should be developed to advise devs of the minimum reqs
to fulfill. I see this as a separate project for the project in the future. People are
going to need PHP4 support still for some time to support legacy webapps
and also because of slack admins.

rgs, Chris

On Tue, 19 Jun 2007 09:23:42 +1000, Brian Jackson iggy@theiggy.com wrote:

I haven't so far because I didn't have a good solution for the older db
library other than just say forget it. I didn't think that would go over
very well, but if mdb2 becomes the only db library, I'd be more than
happy to resurrect the patch and port it to latest svn. I may have even
had at one point a patch to rip out the older db library and leave all
the db access parts connected directly to mdb2, but I'd have to dig a
lot for that.

--Brian Jackson

On Jun 18, 2007, at 5:11 PM, till wrote:

...

On 6/18/07, Brian Jackson iggy@theiggy.com wrote:

...

If roundcube did switch to requiring mdb2, I have a local patch that uses mdb2's xml schema stuff to automatically install and maintain the database table layout.

Very cool, maybe you want to open a ticket on the trac?

Cheers, Till

Chris Fordham wrote:

As said by others, there does need to be a reason for PHP5 change. Is there any proposed code that requires PHP5, probably not.

There are a few:

• better OOP with abstract classes (e.g. address book sources) and public/private/static declarations
• getting rid of the object reference issues

Of course the devs can make use of all the other nice features of PHP5 like exceptions, object iteration, autoloading, etc.

My vision would be that RC changes to PHP5 in a major release eg. Roundcube 2.

Just to mention the background of this thread:

Till is working on the vNext version which will be a major release and surely will take much time to complete. This includes a partial rewrite of the RoundCube code to make it more object oriented with a new approach for the client-server communication as stated in the draft (http://trac.roundcube.net/trac.cgi/wiki/RoundCube_vNext)

With all these changes, we could also get rid of our database abstraction class and either use PDO or implement MDB2.

~Thomas

Thomas Bruederli wrote:

There are a few:

• better OOP with abstract classes (e.g. address book sources) and public/private/static declarations
• getting rid of the object reference issues

Of course the devs can make use of all the other nice features of

PHP5 > exceptions, object iteration, autoloading, etc. I just agree! I've been working on large PHP4 and PHP5 projects and once you get used to the new features that PHP5 offers you just want to use them.

We have 2007, PHP5 has proven to be reliable and stable, so don't be afraid of going for it.

With all these changes, we could also get rid of our database abstraction class and either use PDO or implement MDB2.

Exactly - PDO is a really nice way of accessing the database, it's fast, reliable and just works for a lot of different databases! Don't stay with PHP4!

Mike

Depending upon the server (apache, lighttpd, etc.) an entirely new box is not necessary to run php4 and php5 concurrently ;)

~Brett

Robin Elfrink wrote:

till wrote:

...

Can people elaborate why PHP4 is their only option. Trying to get the big picture. :-)

In my case the main RC install runs on the same box that runs parts of our ordering and product-management system, which is written in php.

A different machine for RC is not an option at this moment, for several reasons.

Robin

till wrote:

It's doable, but not so pretty.

Till

In future more and more hosts will migrate to PHP5 so it makes sense to support the new, modern language which speeds things up and makes development much easier compared to PHP5. If you still develop in PHP4 you are wasting a lot of development time finding reference issues, building an error system, coding with slow DBAL's. And trust me - I did some performance tests, all PHP4 DBAL's are pretty slow compared to something that is implemented in C.

It would be something different and I would agree to not go for PHP6 until it has been around for at least a year.

lg, Mike

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

But does the ordering app not work in PHP5?

Maybe an upgrade vs a new machine?

Robin Elfrink wrote:

till wrote:

...

Can people elaborate why PHP4 is their only option. Trying to get the big picture. :-)

In my case the main RC install runs on the same box that runs parts of our ordering and product-management system, which is written in php.

A different machine for RC is not an option at this moment, for several reasons.

Robin

All looks exciting and active to me!

On Tue, 19 Jun 2007 20:09:00 +1000, Michael Baierl mail@mbaierl.com
wrote:

Thomas Bruederli wrote:

...

There are a few:

• better OOP with abstract classes (e.g. address book sources) and public/private/static declarations
• getting rid of the object reference issues

Of course the devs can make use of all the other nice features of

PHP5 > exceptions, object iteration, autoloading, etc. I just agree! I've been working on large PHP4 and PHP5 projects and once
you get used to the new features that PHP5 offers you just want to use
them.

We have 2007, PHP5 has proven to be reliable and stable, so don't be
afraid of going for it.

...

With all these changes, we could also get rid of our database
abstraction class and either use PDO or implement MDB2.

Exactly - PDO is a really nice way of accessing the database, it's fast,
reliable and just works for a lot of different databases! Don't stay
with PHP4!

Mike

PHP 5 is progression. PHP 4 is stagnation.

developer-support@allknightaccess.com

All Knight Access Be somebody without selling your soul. http://www.allknightacccess.com/

On 6/20/07, Michael Bueker m.bueker@berlin.de wrote:

On Wednesday 20 June 2007 20:07, All Knight Access wrote:

...

PHP 5 is progression. PHP 4 is stagnation.

Have you been developing slogans for communist parties lately? :D

If you support opensource, you support communism - ...err wait, that was for a different mailinglist. ;-)

Anyway, all in all I am pretty happy with the feedback, still - keep it coming. Right now it looks like half/half. Taking in account that devel-vnext will not be released by tomorrow I think we'll look into a PHP5 only port with PHP6 in mind.

For database, I haven't made up up mind yet. I am leaning somewhat towards a DBA(L) like Doctrine (0, 1) because it adds shortcuts and helpers (query builder, sequences, etc.) which straight PDO may not have.

Sidenote - I pretty much finished implementing the rc_registry (2) today, I replaced almost all globals so we are 99% complete (or globals-free). Of course I also introduced a couple errors but all in all it works. ;-)

Cheers, Till

0, http://lists.roundcube.net/mail-archive/roundcube.dev/2007/06/149/ 1, http://doctrine.pengus.net/trac 2, http://trac.roundcube.net/trac.cgi/browser/branches/devel-vnext/program/incl...

Hi, I'm running PHP5 together with PostgreSQL as DB. I don't know much about MDB2, but I think PDO is the best abstract layer for DB access. Regardless PHP5 vs PHP4, I think OOP is the only way to keep a project flexible while growing and it makes team work easier too. PHP5 can benefits of objects properties like inheritance, abstraction, interfaces, code reuse, exceptions handling,... Programming with object-oriented syntax the code becomes more readable and the project can benefits of it a lot.

Andrej Mocilnik

till ha scritto:

On 6/20/07, Michael Bueker m.bueker@berlin.de wrote:

...

On Wednesday 20 June 2007 20:07, All Knight Access wrote:

...

PHP 5 is progression. PHP 4 is stagnation.

Have you been developing slogans for communist parties lately? :D

If you support opensource, you support communism - ...err wait, that was for a different mailinglist. ;-)

Anyway, all in all I am pretty happy with the feedback, still - keep it coming. Right now it looks like half/half. Taking in account that devel-vnext will not be released by tomorrow I think we'll look into a PHP5 only port with PHP6 in mind.

For database, I haven't made up up mind yet. I am leaning somewhat towards a DBA(L) like Doctrine (0, 1) because it adds shortcuts and helpers (query builder, sequences, etc.) which straight PDO may not have.

Sidenote - I pretty much finished implementing the rc_registry (2) today, I replaced almost all globals so we are 99% complete (or globals-free). Of course I also introduced a couple errors but all in all it works. ;-)

Cheers, Till

0, http://lists.roundcube.net/mail-archive/roundcube.dev/2007/06/149/ 1, http://doctrine.pengus.net/trac 2, http://trac.roundcube.net/trac.cgi/browser/branches/devel-vnext/program/incl...

for me, it doesn't matter which version of php you choose as we support both, php4 and php5. so far i'm running on php4 as this is the default setting and there hasn't been any reason to modify this setting.

from a developer point of view i would switch to php5 - at least with vdevel-next to ease development.

so take my mail as a vote for php5 ;)

kind regards, raoul bhatia

till wrote:

On 6/20/07, Michael Bueker m.bueker@berlin.de wrote:

...

On Wednesday 20 June 2007 20:07, All Knight Access wrote:

...

PHP 5 is progression. PHP 4 is stagnation.

Have you been developing slogans for communist parties lately? :D

If you support opensource, you support communism - ...err wait, that was for a different mailinglist. ;-)

Anyway, all in all I am pretty happy with the feedback, still - keep it coming. Right now it looks like half/half. Taking in account that devel-vnext will not be released by tomorrow I think we'll look into a PHP5 only port with PHP6 in mind.

For database, I haven't made up up mind yet. I am leaning somewhat towards a DBA(L) like Doctrine (0, 1) because it adds shortcuts and helpers (query builder, sequences, etc.) which straight PDO may not have.

Sidenote - I pretty much finished implementing the rc_registry (2) today, I replaced almost all globals so we are 99% complete (or globals-free). Of course I also introduced a couple errors but all in all it works. ;-)

Cheers, Till

0, http://lists.roundcube.net/mail-archive/roundcube.dev/2007/06/149/ 1, http://doctrine.pengus.net/trac 2, http://trac.roundcube.net/trac.cgi/browser/branches/devel-vnext/program/incl...

On 6/21/07, Michael Baierl mail@mbaierl.com wrote:

On Thu, 21 Jun 2007 10:15:08 +0200, Andrej Mocilnik amocilnik@dotcom.ts.it wrote:

...

Hi, I'm running PHP5 together with PostgreSQL as DB. I don't know much about MDB2, but I think PDO is the best abstract layer for DB access. Regardless PHP5 vs PHP4, I think OOP is the only way to keep a project flexible while growing and it makes team work easier too. PHP5 can benefits of objects properties like inheritance, abstraction, interfaces, code reuse, exceptions handling,... Programming with object-oriented syntax the code becomes more readable and the project can benefits of it a lot.

In my opinion a real DB abstraction that also abstracts all your SQL queries like MDB2 works against the speed improvements you have when you use PDO. I don't see what's wrong with SELECT * FROM table WHERE id=? compared to $q = new SelectQuery(); $q->selectFrom('table'); $q->where('id', $id);

.. just making this up now, but I think the first one is much more readable.

And honestly, on which databases will Roundcube exist? Most probably 98% MySQL.... don't invest too much time in the 2% other users.... it's not worth the effort!

Get outta here. ;-)

Roundcube will maintain and improve its support for different database engines. That has never been a question.

Using a DBAL would improve handling - that's all. For example you write a query, add a limit and it works on MySQL, Oracle and Informix

• the DBAL would take care of that. I think we are far from looking

into building yet another DBAL. :-)

Cheers, Till