Boy IB3 and VBulletin sure resemble ..

[[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.

[upperking]

perl/mysql

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

[[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.

[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.

[chrispadfield]

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

[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....

[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.

[[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!

[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?

[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)

[[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.

[4php]

Originally posted by [email protected]

My biggest problem with PHP is that it's oversimplified to the point where their are a thousand commands to do the same thing.

There are heaps of functions, if what you say has some truth to it - how about a few examples ?
what are these commands that do the same things ?

I have nothing against perl either.

[tubedogg]

If you take a glance through the PHP manual, there are a number of functions that duplicate each other. I can't think of any off the top of my head, but there are at least a few.

[4php]

Well I guess you could say that posix compatible regular expressions and perl compatible regular expression can do the same thing, even some of the string functions like str_replace() can do the same thing.

Just because functions can be used to do the same thing doesn't mean they should be used in the same situation.

[[email protected]]

I'd better clarify before this gets out of hand

I wasn't saying that PHP is a bad language. I was just illustrating my point from my perspective. I've been coding perl for about 10 months and pretty much know 80% of it inside out. I found it frustrating that I couldn't write stuff like 'do_thing() if $var;' - it felt like I had to write it all long hand.

Again, PHP seems over simplified from a perl coders point of view. To me it was confusing to see so many overlapping functions.