Topic: What can we do to help grow our 3PDs?

[Night09]

Think of it this way -- What's stopping you, for example, from creating such a site?

Bandwith? 

[Fustrate]

Confidence!

The main thing that troubles me is that there are tons of mods on SM.org, and I doubt many new mod developers would waste their time adding mods to a new site. There's also the gazillion mods that are orphaned and couldn't be moved, since the authors only gave permission to SM.org to ditribute it when they uploaded it, not some fancy schmancy new place.

So if that could be reconciled... I wouldn't undertake the project all myself to try to launch it, but I'd certainly work hard on it if a few other people would do the same.

[Orstio]

Confidence!

The main thing that troubles me is that there are tons of mods on SM.org, and I doubt many new mod developers would waste their time adding mods to a new site. There's also the gazillion mods that are orphaned and couldn't be moved, since the authors only gave permission to SM.org to ditribute it when they uploaded it, not some fancy schmancy new place.

So if that could be reconciled... I wouldn't undertake the project all myself to try to launch it, but I'd certainly work hard on it if a few other people would do the same.

Very good.  I wouldn't be so sure that new mod developers wouldn't want to add their mods.  It depends a lot on the environment.  Some mod authors do some good work, but get jaded by the requirements of the SMF mod site, for example.  Perhaps that would be a good audience of mod devs to target?  Some mod authors want to make their mods commercially available, or include advertising text, or other things that simply can't be done on SMF's mod site.

[Fustrate]

Do you think there's any possibility that the devs here would share some of the code behind the mod site? That way, we wouldn't have to reinvent the wheel...

[Eliana Tamerin]

I'd be willing to help you out with that, Yoda. As an individual, not a team member.

[Dragooon]

I can possibly help too Yoda, it has always been in my interest to do such a thing.

[Fustrate]

Orstio - I see you own SMForge.org... and possibility of using that? Dragooon sent me a PM titled "SMF Forge", so I looked up the availability and saw you own the best url for it

[Rumbaar]

We seem to have plenty of third party SMF sites:
www.tinyportal.net
www.simpleportal.net
www.smfthemes.org
www.smfforfree.com
www.smfhacks.com
www.ezportal.com
www.smfarcade.info
www.smfads.com

Those are just the english ones I can think of off the top of my head. Now of all of those who have heard of them?

If there is no 'marketing' from the SMF side of things or a need for them.  Then they will die.  With SMF being the 'one stop shop' for all things SMF (Core, themes, mods) how would a dedicated third party hub for mod/theme developers help the third party growth?

I think 'we' as SMF allow quite a lot of freedom from our mod/theme developers.  We give them guidelines, tips and direction.  Then we give them a forum to host and spread their creation to the masses.

I could open a SMFdevelopers site tomorrow.  Have a front end and even use the available mods to make a download, blog and portal system for them to communicate to the SMF community and support their creations.  But who would come?  Who would use it?  What added benefit would it be, other than a more relaxed environment to have a mod/theme available for download.

But possibly if you build it, they will come.

[Fustrate]

and that's the conclusion we came to in private discussion... it's already splintered out, so there's no real point in creating another one.

The only thing I see with those is that they either promote a single mod or a single developer (or development group)'s mods. Just an observation. Well, except for smfthemes.

[Rumbaar]

Well a single mod or single developer is still a branched third party development, which I assumed was the point of this thread.  It wasn't for a duplication of the things we have here, but to facilitate a growth in 3PD's.

But strange enough the XOOP example given earlier of their 3PD's, 3 out of the 5 site mentioned are no longer active and 1 of them is just a language specific support 'mirror' of the main one.  Which we also have for various languages.

But I wouldn't say it's splintered out, I would say that at least 90% of people searches result in the single location for their SMF needs, and that is here.

[Ensiferous]

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.

[Arantor]

Mostly valid points, that.

Though I'm not a rep for SMF, I would argue the following:

• Globals have a place. Just as Goto does. Not all styles of programming support it, not all programmers like it, but there is a place for them.
• A forum can be the entire site itself. Or it can be part of it. Like everything else it depends what you're trying to do. The exact same argument holds for phpBB3 actually. I personally think SMF does the balance fairly well with SSI.php
• I'm currently building an MMORPG that uses SMF for the forum and also to handle all the user authentication. The 2,000 lines is actually smaller than some of the auth classes I've seen, including Zend Framework's.
• If modules don't depend on a core, they by definition have to redo some of the stuff the core does.

[Ensiferous]

Globals never have a place, they make it impossible to use unit tests and you have no clear point of definition, basically you have no idea what data you're working with or where it comes from, they are a relic from the past and should not be used in any modern code.

A forum can be the entire site yes, but not for any serious project, the sort of developer who might create quality mods for a forum would be unlikely to have a forum site only, usually the type of people who run those projects are people who can't create a product themselves and thus rely on scripts other people made. Thus why I feel it's relevant to this topic as they're specifically asking for ways to make themselves more attractive to third party developers.

As for the 2,000 lines of code, it was a guestimate to the lines of code that didn't deal with the actual function (in this case user authentication) but rather with various other stuff such as templating, sessions, security, permissions etc. In actuality, the number is far, far larger as subs/load.php alone is 2500 lines. Regardless, citing one bad example as a valid reason for bad code is not a really good argument. Zend Framework is not the pinnacle of good code.

As for the modules not depending on the code, you have a point, except I'm in favour of a minimal core that doesn't really do anything but direct code flow to the right parts. Think of it in a layered way, you have a model that analyses the url to determine which action to take, then loads a controller to do so, that controller then loads the various modules and loads the forum as appropriate.

If a module then only depended on other modules then they should be loadable from outside the forum framework without too much fuzz and the various bridges to other sites and scripts would merely be to define a new module loader.

I'm by no means saying it would be easy getting a system in place like this, but it's definitely not impossible.

[Arantor]

I have yet to see any sufficiently large piece of code that doesn't use globals at all in any way shape or form (other than globally declared classes). I can give you one excellent reason for globals in the case of SMF though - performance. It would be interesting to see what the SMF developers make of my take on the design decision.

I see it that if you have data that persists for the life of the script's execution - i.e. for the entire page generation, putting into a global scope for that script makes perfect sense. So when we initialise we populate $context with the data of who the user is. If we objectify everything we would logically need to make a User class and make the current user a property of an instance of that class. Then we have to pass the property of that class any time we need to use it, meaning that every time we do a function we have to be sending that data between functions. This will be slower than calling it into scope from outside when you do it a lot (i.e. more than once)


Regarding forums being the entire site, I know of some places where it is by far the main part of a site, and everything else being a bolt-on to it, some that support people very comfortably in fact. It just depends on the project and its aims. But take a look through Showcase - the number of people for whom the forum is the site is the forum is quite surprising.

Actually, under the hood SMF is fairly modular - a check of the Function DB would confirm that is the case.

Regarding the large size of includes; agreed SSI is not as minimal as perhaps it could be, but it has to be a fairly generic thing lest you have a module for each part (one for authentication, one for getting posts, one for getting user details) and moving that to the SSI user-developer to implement. In fact, though you say ZF is not the pinnacle of coding (which it isn't), the manner of objectification you're suggesting - giving each specific area its own module is precisely how ZF is arranged. Whether the individual lines of code are poor, the structure is that which you are arguing in favour of.

2.0 is already a fairly big rewrite versus 1.1 - what would you expect to see in 3.0 that completely rewrites 2.0?

[Ensiferous]

You're severely underestimating the power of the CPU, the speed difference between the two programming styles is measured in micro seconds and you will not lose many requests per second. Personally I find the tiny speed degradation worth the gain you get in ease of programming. Besides, you're optimizing in the entirely wrong area, most likely 90% of your script execution time will be spent waiting for the file system of the database. If you want to optimize things then cache things that actually take up time, don't micro-optimize. Besides, premature optimization is the root of fluffy and cute.

I'm not saying that forum-only sites doesn't exist, I'm just saying they're rarely run by the type of person who consistently produce their own code and would be willing to help out with third party addons to SMF.

As for Zend Framework, personally I believe they abstract things a bit too much and use too much magic with cross includes and a much too much complexity. That doesn't mean they aren't going in the right direction, pretty much any PHP framework these days uses a MVC structure, Zend, Solar, CodeIgniter. It doesn't really matter, in the end they all use OOP code since it promotes readable code that's modularized and easy to make heads and tails of.

[Arantor]

Actually, time of execution in SMF seems to be about 50/50 split according to the questions on it; and where it's skewed towards the DB it's usually because the DB isn't tuned to best performance, not because of the application. I wasn't thinking so much of the 1-or-2 executions, I was thinking of such things whereby if every function call and every loop is referring to a passed-by-reference variable (which it always will be with strings, for example) it's going to be more than a little speed degradation versus bringing things into scope from global.

The argument of OOP vs algorithmic is going to rage far longer and wider than here, and if it's something you're really passionate about, a debate in Coding Discussion is the way to go; for example, take MediaWiki - that's much more OOP styled (and has global vars!) and I'd argue that it's harder writing a mod for that than it is for SMF.

I see where you're coming from, but the rewrite you're talking about is even bigger than SMF 1->2, and I'm not convinced a rewrite of that magnitude would help a 3PD any more than leaving it as it is now - nor do I think the developers of SMF are.

What would a 3PD want from SMF in terms of being able to integrate? Off the top of my head the really big things:

• Ability to use SSO - doable via SSI.php
• Ability to retrieve posts - doable via SSI.php
• Ability to display current member information - doable via SSI.php

There are more - I know there are. But each time SSI.php covers it, and if it doesn't it's not a huge leap away to get it. I'd hate to use multiple classes for these tasks that, for me certainly, go together. In fact, it definitely goes together - if you want to get the latest posts you need to know who is logged in, and thus what posts they can see. Thus you need each time to depend on that auth system, which means you instantiate that class each time.

Anyway, we're getting off-topic, the debate here was about restructuring SMF to support 3PDs; SSI.php and SMF_API are the two cornerstones thus far to doing that. As a 3PD developer how would you expect to see SMF? Saying it should be OO is fine but it would help to have some idea of what you're envisaging since that can be put forward as a suggestion for 3.0.

[Ensiferous]

I think I argued what I would like SMF 3 to be fairly well, if you do not yet at least see what I've suggested what I'd be interesting in writing mods for then I don't think I can explain it well enough, because I certainly don't know how to explain it differently.

[Arantor]

I see the general idea you want, you want SMF to be object oriented in design. What I'm trying to get at is how you would want it to be structured at a deeper than "just OO" level.

I mentioned MediaWiki; it's 'object oriented' in design but just about everything lives in the User object. How would you as a 3PD developer want to find SMF? A single master User object with every method attached? Multiple objects? One per major module of SMF? (e.g. DB, User, Post, Board, Template) or something else entirely?

[Ensiferous]

The key is separation and isolation of objects, if everything lived in one object you might as well not use object orientated programming. Ideally each function would have it's own module, so for example a class would exist for user functions such as authenticate, login and logout amongst others. This module would then depend on a MySQL object (which would inherit it's structure from an abstract SQL class) and a validation object.

Each object would be loaded by a central loading class so you could cache already loaded objects and use dependency injection with modules, that way you can easily unit test the whole thing.

Done right the bridging with other systems would involve writing your own version of the loader (possibly extending an abstract class that defines what must be implemented), if you wanted to you could then inject your own code instead of the SMF code so long as it implements the proper methods.

It's not something you cook up on the spot, it takes a lot of planning and I'm honestly not inclined to work up a system like this for something that probably won't happen, I don't have that many hours to throw away.

[Arantor]

I just meant a three or four line overview of how you'd expect to see it, not a complete overview diagram of intermixed modules and dependencies, but I have a better idea where you're going, and in an ideal world it might help. Though I would still worry about performance - lazy loading modules is not always as/more efficient as/than always loading, when you have filesystem and bytecode caches in play at least.

The biggest problem now is that there are bridges to other CMSes (e.g. Mambo, Joomla) that would need to be completely rewritten to support such a move; you might as well start over and not reuse the SMF base in that case.

Thank you for your input and discussion, it's been interesting to see how others perceive the code base.