Boy IB3 and VBulletin sure resemble ..

[[email protected]]

The support boards are not running under mod_perl, we're waiting for the replacement server before we install it.

mod_perl isn't easily installable on 'shared' servers, but more and more dedicated servers have it pre-installed (or can install it). It's not that hard a process, simply chuck in a few modules and mix with an adjusted apache config and reboot. I have it installed on my old Mac server (used for local testing).

Wert, I'm not saying that you should use a Perl script, all I was originally saying is that Perl isn't a slow language.

My biggest problem with PHP is that it's oversimplified to the point where their are a thousand commands to do the same thing. I've written a few PHP scripts for use on the ikonboard site and I couldn't get on with it. It smacks or perl for the terminally lazy (no offense intended!). Perl maybe old (if you forget about the frequent updates) but to me, it's still the most fluent web language.

[chrispadfield]

i would think that by the time you need mod_perl for performace reasons you are going to be well on your way to a dedicated server.... then you can install it yourself (although i here this is not a trivial procedure)

[wert]

Good points all, but...

... it seems that the vast majority of us on shared servers don't have mod_perl installed. Without this, why would I install a perl/cgi board that's gonna be slower without it? Is there any reason that hosts wouldn't want to install mod_perl? Possibly because it supposedly breaks many older perl scripts Also, what would the comparison be between using regular perl and PHP 4.0.4pl1 with the zend optimizer? Is the alpha site of Ikonboards using mod_perl?

[[email protected]]

Wert, Yes you can remove the CGI process. There are several languages that can be compiled and run by a Common Gateway Interface Perl is just one of them.
PHP is fortunate that it's run as a compiled language on the server. That's mod_php. The server loads the script up once, and treats it like a continously running process (a hugely simplified explaination!), negating the need to load it, compile it and fork it.

Perl has this ability too, mod_perl. It'll enable the apache (usually) registry to load the CGI script once (and up to 10 external modules) and treat it as a continously running process.

I'm doing my best to ensure that iB is not only mod_perl safe, but actually takes advantage of the apache registry.

Hostrocket have huge problems with CGI. I can't believe a web hosting firm's (who am I kidding) advice to it's paying customers is 'Dont' use CGI, it sux' after being innundated with support requests for CGI scripts.

Is Ikonboard a resource hog? Certainly no more than vBulletin. 99% of the stories you hear are almost always based around an empty board and 'hypermart', who take down anything that's not HTML.
The other 1% are usually from someone trying to run a board with 200+ online members on a $4.99 a month special 'shared' server deal.

4php - I agree, which is why I'm writing a 'glue layer' module for database access. The scripts will have a fairly standard interface - nothing involved with actual database access, the real grunt work is taken care of in the glue layer. That's how Time Bunce wrote the DBI module which seems to work well!

[4php]

Originally posted by [email protected]
Excellent.

At the moment I'm rewriting several key modules to allow the database module to be 'plugged in'.

As Tim Bunce wrote the DBI, and hundreds of people have written DBI's, Ikonboard 3 will have the ability to use one of the following database types:

Flatfile
DBM's (Berkely Database)
DB2
Empress
Fulcrum
Informix
Ingres
miniSQL
mySQL
MSSQL
PostgresSQL
QuickBase
Solid
Sybase

Which is nice.

It is - but unless you use features such as stored procedures, and triggers in the datbases that support them - you will be missing out on a HUGE performance boost.
Not using them would be like buying a Ferrari and going at 50mph all the time.

Unfortunately not all databases have the features you want - eg LIMIT so you have to do workarounds.
Database procedural languages can have very annoying differences too, some lack things you really want.
But it is worth it in the end.

Putting a lot of the applications work into the database really cuts down on your the length of your scripting languages code.

You also forgot Interbase and firebird(breakaway open source interbase). It is becoming more popular and is a very good open source database.

[wert]

Originally posted by [email protected]
[B]Grrrr

[Pet Hate]

Perl is NOT slow, it's as fast as PHP. It's the CGI process that slows perl down, not the code.
I'm getting seriously fed up of people who don't know anything tell me that perl 'sux' 'cos it's slow.

[/Pet Hate]

Probably a silly question. If it's the CGI process that's slowing it down, will it ever be faster? Can you eliminate the CGI process in some way and still run Ikonboard? I'm ignorant of such things, but curious. Would running IkonBoard with a "plugin" dbase like mySQL eliminate the CGI process and speed it up? Not to be mean, but it's slow on many servers, not just yours. Especially the search function. Maybe this will be fixed in 3.0, but the alpha on your site still seemed broken in this regard.... I've had more than one hosting webmaster refer to IkonBoard as a "resource hog". Is this an unfair charaterization? I know where I host, *hostocket* people use vB, phpBB and the like and with no problem, but Ikonboard seems to cause problems. I'm always looking to test out new boards, so I await the final of 3.0 so I can run a test board and compare it directly with with the php/mySQL boards....

[chrispadfield]

that is nice, ikonbaord really looks like it is going to take over quite a lot (any of UBB anyway!).

[Jordan]

Seems like the word is that Ikonboard is Open Source. Ikonboard is NOT Open Source. There will be a new license agreement with iBv3.

[[email protected]]

Excellent.

At the moment I'm rewriting several key modules to allow the database module to be 'plugged in'.

As Tim Bunce wrote the DBI, and hundreds of people have written DBI's, Ikonboard 3 will have the ability to use one of the following database types:

Flatfile
DBM's (Berkely Database)
DB2
Empress
Fulcrum
Informix
Ingres
miniSQL
mySQL
MSSQL
PostgresSQL
QuickBase
Solid
Sybase

Which is nice.

[upperking]

perl/mysql

i have a friend that has perl/mysql board in the works..

[[email protected]]

Grrrr

[Pet Hate]

Perl is NOT slow, it's as fast as PHP. It's the CGI process that slows perl down, not the code.
I'm getting seriously fed up of people who don't know anything tell me that perl 'sux' 'cos it's slow.

[/Pet Hate]

Oh, and iB 3 may seem 'pokey' because the server we're on is terminally broken. Paul is waiting for a replacement to install at the NOC.

[4php]

Re: Re: Re: mySQL and perl/cgi

Originally posted by fastforward

PHP is almost *too* easy to use. It turns people into lazy programmers.

But, that's just my opinion and I'm slightly biased coz I know Perl better than PHP

I don't know perl - I only know php and tcl - and started with python.
But I totally agree - php makes it so easy to write messy, buggy code.
It also makes it easy to learn php so it's not so bad.

[4php]

Re: Re: Re: mySQL and perl/cgi

Originally posted by wert

So two apps equally well programmed using Perl/CGI and php/mySQL *could* perform equally well? From what I understand, in a well written app, pulling and putting data in a dbase like mySQL is just inherently faster. Is this incorrect?

Yes they could work equally well. It all depends on the programmer. I don't think any speed difference between php and mod_perl is important and shouldn't influence your choice of which to use.

Avaiable hosting, available programmers, maintainability of code is all important to consider.

[fastforward]

Re: Re: mySQL and perl/cgi

Originally posted by Ed Sullivan
I don't know how correct I am here, so correct me if I'm wrong, but mod_perl and mod_php work similarly, except PHP does automatic variable clearing/"local scoping". To code for mod_perl, you have to declare all variables as local to the script ( my($variable); IIRC). Otherwise these variables would be carried over to the next time the script is run. In PHP all variables created are only going to be used with that specific script.

This is true but it ensures good programming practices by making sure all variables are re-initialized, files closed etc. The 'use strict' ensures most of these problems are trapped. The -w switch should eliminate it all together. Also, if 'scoping' is used correctly, you should never run into this problem anyway.

I firmly believe if PHP had a similar feature to the Perl 'use strict', we'd see much tidier and bug free code in these free PHP apps that are churned out.

Installing mod_perl doesn't mean all cgi scripts have to use it. Scripts can even reside in the same directory and by using the Apache 'FilesMatch' directive, you can use a different handler each time.

PHP is almost *too* easy to use. It turns people into lazy programmers.

But, that's just my opinion and I'm slightly biased coz I know Perl better than PHP

[Mike Sullivan]

Re: mySQL and perl/cgi

Originally posted by wert
How many hosts have mod_perl installed?

Shared servers? Virtually none, for the fact that it makes many perl scripts not work. Like Matt Wright's, although no clue why you'd want to run one of them anyway.

I don't know how correct I am here, so correct me if I'm wrong, but mod_perl and mod_php work similarly, except PHP does automatic variable clearing/"local scoping". To code for mod_perl, you have to declare all variables as local to the script ( my($variable); IIRC). Otherwise these variables would be carried over to the next time the script is run. In PHP all variables created are only going to be used with that specific script.

mod_perl just basically requires you to code with strict on, which isn't particularly a bad thing.