Wedge

OK, let's back up before any FUD starts flying.

Cast your mind back to late 2005 when SMF 2.0 started development. PHP 5 was still relatively new, and due to PHP's licence change, classic client MySQL (the mysql_* functions) was no longer compliant. That's why the MySQLi interface even exists, in fact.

Alongside this, PHP 5 was bringing SQLite with it, enabled by default, so in theory any host with PHP 5 would have SQLite support enabled. And with MySQL being tenuously supported it seemed reasonably logical.

There's the reason for it.[1]


The empty parameter is not always empty. Yes, it's only used in a few queries but they're ones where MySQL's syntax isn't compatible with either PostgreSQL and/or SQLite, and there was no need to slow down *all* queries for the sake of the minority. For example, there's a RAND() reference in there; except on one or other, it's RANDOM() not RAND(). Since it's only used in one place, there's the logic of using specialist replacements.

Honestly, if they were going for proper abstraction, the best place to start would have been upending the schema and removing FIND_IN_SET which is the single biggest barrier to PostgreSQL use, not to mention shooting performance in the foot on anything that isn't MySQL.

It claims to support these other platforms, but it only really gives the impression of doing so; you'd have to up performance by an order of magnitude on the backend to see an improvement in the application as a whole because of the fact that FIND_IN_SET (which is so heavily used in MySQL/SMF) is not available in PostgreSQL and is implemented as a user defined function. Guess how much that hurts performance.

1.	I'm not defending it, because it's not defensible. But there it is.

Oh, and the news fader also no longer has the infamous bug where it breaks in IE just on any custom theme because the theme author doesn't explicitly state a colour for the background. All part of the service, so to speak ;)

Let's be honest for a minute.

Of the current dev team, one of them has outright said he is "just the markup guy". One of them is a capable modder/coder, the other is relatively unknown. Between them, that doesn't really spell 'vision' to me.

EDIT: Getting rid of GIFs can be advantageous but doing so just because you want rid of GIFs isn't particularly clever. Unless he means fresher images too...

Not really that interesting, nor that surprising. Any developer with an ounce of intelligence is going to be considering 'the next big thing' whilst finishing up 'the current big thing'. (We're on the ramp up, so everything here's on 'the current big thing')

But seriously, SMF 3 will be a from-scratch rewrite for it to meet the things they've hinted they want to do. Guess how long that takes.

I hope they know what they're doing. I really do. For their sake.

http://www.simplemachines.org/community/index.php?topic=432988.0That gives them a shade over 3 weeks to fix the 32 bugs currently tracked. It's feasible, but honestly... they now have to deliver because not doing so will make them look like the biggest laughing stock going, and they will lose what little credibility they have left.


EDIT: Corrected typo.

Avast and Norton is probably *the* poster child for how free stuff does it so much better, -sigh-

Then we should find some other ways of competing with the big boys; price isn't everything.

What I do know is that if you go for the paid systems, they *do* have a better track record of providing support because they can pay people to provide support.

That said, a decent amount of the problem is in building it right in the first place; how many of SMF's support questions are manual related?

I'm also seeing an awful lot of encoding issues lately, which is something else we've already tackled.

That was the idea, yeah, to put a distinct mental shift on my involvement there... and I found myself still unable to go entirely cold turkey on not posting there :(