I'd like to apologize up front, because as I wrote this some of my frustration with SMF code turned it into more of a rant than I had originally intended.
Old topic but I figured I'd just give my opinion seeing as I actually work a lot with SMF - or rather, against SMF. Because working with SMF code is a battle, and we're not on the same side.
To reiterate a point made I think was very valid. "The problem with SMF is SMF itself"
You say you strive to modularize it and make it more API like, but I'm running SMF 2.0 RC1-1 and I honestly don't see this. You just have to look at ssi.php to see my point, this is the supposed file for integration yet it sets no less than 32 global variables and include 6 files outside of the settings file.
This isn't integration, it's building stuff on top of SMF - and that's the totally wrong way of going about it. The forum is not a central part of a site - at least not for anything serious - if you think like that you doom your software to be used by 12-year-old and "install and forget" type of people. If you want developers to use it then a shift in programming methods needs to happen with SMF developers. You need to seriously reconsider your entire codebase. Usually I'm not a guy who will rewrite things because you just end up redoing the bugs you already did once, but I'll make an exception for SMF. Start over, scrap PHP 4 support, (seriously, not even the php devs support it any more, forget about the people who are still running it) and work on a code structure that will allow people to integrate SMF into their software, not the other way around.
That's not to say SMF shouldn't offer stuff such as user system and calendar, but it should work perfectly fine using info given to it by another system. Naturally this info would have to be in a specific format, but so long as a programmer doesn't need to include a butt load of your code to use it then it won't be a problem.
A lot of my pet-peeves and cringe-worthy things about SMF actually shows in the SSI file.
$smcFun array with links to functions is just about the most stupid thing I've EVER seen, and I've seen a lot of stupid things. You hide the functions you use in an array so that I have no idea where the hell this function is defined.
Also it seems SMF is re-implementing php functions as in "$smcFunc['strlen']".
SSI is practically a joke, if I want my site login to be the same as my forum login then I don't want to include 2,000 lines of SMF code, I want a simple class I can instantiate, feed a mysql resource link as well as user info to a method and then have that class do what it must.
At this point in time it's impossible to do with SMF, at one point you had a smf_api.php file going which was a step in the right direction. I basically took this and started maintaining it myself to do what I needed it to do without including all of the SMF code - sadly, you've abandoned this.
Since I got off-track and repeated myself a bit I'll just reiterate my points:
- Realize a forum is a part of a site and not the site itself. It should be treated as such.
- Forget about PHP 4, it's old, it's not supported and it's horrible.
- Start over. Restructure code and API and modularize it, in a perfect world none of your modules would depend on the core itself, that way it can easily be included in any other project and used.
- NO GLOBALS! Ever!
So in my opinion, get SMF 2 out the door and then start on SMF 3 from scratch. Then I could see myself helping out with code contributions to the core and via mods - but right now? No chance in hell I'd spend the time required to even understand SMF code.