For Extrm_Bob,
In reply to:
I don't know enough perl to code any hacks.... Much more can be accomplished with php with less effort than with perl.
Wrong, maybe for you, but not for everyone. This isn't a criticism, but both php and perl are just tools to accomplish goals. I might feel that I can do better at banging in nails with a screwdriver because I've never used a hammer or don't know how to use one. In the right hands either tool can be a very very effective one and as to which is better, opinions vary, and since I've never used php, you can probably figure which way my opinion goes. But it's just that, my opinion.
For Scream,
I can understand it's more work and feature sets would need to remain the same and I certainly understand you probably had a very difficult time making that decision and that you probably anticipated some of the comments you are getting now... And in case for any reason I haven't thanked you for a great product, Thank You. While I commend you for making the difficult decision and what you feel was best for the product, I just find it disheartening since here we've spent a lot of money (not even counting our own man hours spent working with this) and that now the product we use will now go unsupported.
In reply to:
PHP is easier on the server under high traffic
Maybe in a comparison against plain perl, but that's not really a fair comparison now is it. Let me give you a quick stat on our forums, running both web and database on a single server with mod_perl, mod_gzip and plenty of other stuff running, including an ad banner system running under plain perl. 57 users online right now, mysql cpu usage is 9% and load is 1.3. At one point when I was looking at this info last night it was like 140 users online and mysql at 18-22% cpu, iirc. And that's on a freebsd box which is not running the linux threads library but does have a dedicated mysql install for the forums. And I know we can do even better.
In reply to:
Speed is definitely a focus. Which is another reason PHP is the logical version to focus on. Most everyone wants templates. Dynamic templates under PERL, especially mod_perl is virtually impossible to do without some major slowdown issues.
I hope it will be, that's what we have spent and been spending a lot of money on here because we couldn't wait for the development cycle to catch up. But again, please don't argue that php is the logical tool for either speed or templates. Speed I covered above and for templates I only have to point to gossamer-threads.com's products... links sql has supported templates for quite some time, it runs great under mod_perl and last time I checked they did not have any of their products in php. Their webmail and (now) forum packages run the same. We own copies of both links sql and their webmail product because we wanted the best products for the money we spent and that's why we bought w3t too. Ultimately it still comes down to a personal preference for the person doing the programming and what their capabilities, and preferences, are. It's just that php is not my tool of choice and I do very well now without it.
And for seb
In reply to:
If there's anything to celebrate, it's probably the fact Infopop felt w3t threatened their product too much.
Scream has developed a great product but from ubb's perspective, I'm not sure they felt as threatened by Scream as they should be of gossamer-threads. As a one-man show, it's always much harder to compete with the "big boys" and this decision could make a great combination. But the timing of all this along with gossamer's announcement of their own forum software (which is threaded), combined with all their other community tools and the ability to integrate everything into a single login and have templates, if I were ubb, I'd be very worried. Their products aren't the cheapest on the market, but damn they are impressive.
Please don't take any of this the wrong way, I'm simply expressing my disappointment over the decision that was made in the world of how it affects me. Because the perl version will be unsupported, I don't think it's a stretch to assume than any of the performance gains that come from future optimizations of mysql and such will ever find their way into the perl version, which is a shame for everyone who wants to or has to still run the perl version.
Here's a thought. Take it for what it's worth. Maybe there's an opportunity to sell off the perl development branch to someone who would be interested in and capable of growing that. Yes I understand it would compete to some extent, but with a limitation of no php development (which is all ubb is interested in) and some sort of royalty deal on sales, who knows, maybe someone is out there for this... yeah, yeah, it's a wild off the wall idea, but there could be a win-win in there for someone.
