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

[karlbenson]

Indeed thank you Arantor and Ensiferous for this discussion.

I think it will obviously need some time to digest.  I just wanted to say these sorts of posts on the structure of smf are not superfluous.
At the moment the devs are working towards getting 2.0 completed, and then obviously we will begin further planning for the next iteration of SMF.  So this is obviously the right time to propose/discuss these sorts of changes.
(although we might want to break off these responses into a separate topic on the future structuring of smf architecture/code.)

As for PHP4, we were already working on 2.0 before php4 got officially mothballed, so it didn't make sense to strip php4 support, since support required only a few compatible functions under the current coding style.  I don't think any decision has been taken about support for it for next smf. (I personally wouldn't be against dropping php4 support).

I would quite like a better MVC approach for smf, although MVC and OO aren't necessarily mutually exclusive. Its just that alot of projects doing MVC have done it in a non OO way.

I for one have opted to be notified for future posts in this topic, and I know a post has already been made about this topic to the attention of the developers. So please continue

* regularexpression goes back to bugfixing

[Daniel15]

$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']".

As far as I know, some functions are reimplemented if UTF-8 is enabled, to support UTF-8 on specific PHP configurations. And one use of the array is for the database implementation - SMF supports multiple DBMSes (MySQL, PostgreSQL, etc.) each of which use different functions. Things like $smcFunc['db_query'] will actually go to the correct function (although, I'd personally use classes that inherit from an abstract class, then instantiate the correct class via a factory method). I was actually saying to someone a while back that an object-oriented SMF would be nice, but it'd be a BIG rewrite that'd require a lot of effort. It'd be nice to see, one day

And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they foumd it too hard to integrate

[Ensiferous]

And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they found it too hard to integrate

I came to the point where I had phpBB3 installed and everything converted over because SMF 1.1.9 performed so horribly bad with a 750k memberbase in certain cases such as banning. SMF 2 RC fixed that though so I opted to save my time on integrating phpBB3 and just adapt my own smf_api.php to work with SMF 2 - but it was close, real close.

[Arantor]

In the case of $smcFunc the idea is that you don't actually need to touch how it's defined; it's an abstraction to handle the different database backends, and is done so in a way that doesn't require creating three classes then lazy-loading and declaring. It's also PHP 4 friendly for the reasons above.

I would suspect the roadmap would be that for 3.0 to strip PHP 4 support and move some of it towards an OO style.

Two big hooks for 3PDs will be some variation on SSI.php and SMF_API. The former isn't geared to full blown app development with SMF; it's designed as a general purpose slot-in to integrate into sites for those people who aren't strongly technical but can manage a little PHP. For example a news feed on a simple site, or to present the login across a wider site and rely on SMF to handle authentication.

SMF_API has more potential for 3PDs in that regard; it's intended to be lighter-weight, and more readily able to get under the hood a bit - but it's not current for 2.0 I believe. That should be the first step, I think.

A third big hook is the codebase itself. The function DB has gone a long way towards simplifying how to access the codebase to do big things with it - plentiful, good documentation never hurt anyone - and I won't deny a clean-up could be used.

What would be really good is for whatever structure 3.0 might have is for it to be posted with a structure diagram and a guide to how it might look structurally so that we can all help hammer it out. Whatever, I think it's going to be a virtual rewrite rather than a code shakedown/restructure.

[Eliana Tamerin]

$smcFunc doesn't just handle databases, if you look at its coding. It's scripted to handle much more than that.

[Fustrate]

$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']".

As far as I know, some functions are reimplemented if UTF-8 is enabled, to support UTF-8 on specific PHP configurations.

To expand on this, not all PHP functions are utf-8 compatible, which is why they need to be rewritten. There are no lines like $smcFunc['strlen'] = 'strlen';

[aldo]

Not sure if this has yet been stated, but it is pretty important I think it wouldn't hurt to restate it XD.

Software previews... or something like that. I know SMF releases beta's and RC's, but for certain projects, it requires more than that. Like TinyPortal (Though the creator of that is/was a SMF dev ) and SimplePortal which use SMF in many ways is a tough thing to do and can take lots of time for the developers to get it properly working with the new version. Developers might get their projects working with SMF beta's and RC's, but each time a new version is released, a lot has changed and then their product cannot be used by clients for awhile until they have it working with the new version.

Basically, these developers need to be able to see what and how SMF is changing before a version is released. I don't mean SMF tell them first, wait a week or more, then release it. But in some way allow third parties to have some kind of access to know more of what is changing in new versions of SMF in a day to day basis.

Basically what I am saying is kinda like what Microsoft and Apple do... When they are developing the next version of an operating system, they give developers access to SDK's earlier than others, sometimes even giving them the whole operating system so they can test on it and what not. It would be a lot for SMF to do, but you could have some kind of team to do something like that.

So yeah
Sorry if some things didn't make to much sense... I am sitting in a 90 degree room .-.

[Orstio]

Yes, I've seen that in other projects as well.  It requires some management -- the same as keeping an active list of beta testers.  You don't want people signing up for access to the latest SVN just to have it, for example.  They have to be actively developing a plugin/mod/extension.
 
It is a very good idea, as it also gives 3PDs an incentive to stay active in their development.

[aldo]

Yeah. That is always the thing... these things have their ups and downs. But if you had a team which could manage that instead of having the SMF dev team (Who should be hard at work developing SMF XD) handle it, it would be workable. Probably slow at first, but after time, it would get better.

[bloc]

I like this idea, and hope it can be something of. But I fear as with earlier projects, that time and manpower escapes it being set in motion.

[Arantor]

Don't forget that Charter members do get it ahead of the rest of us, but I can see what you're saying. You'd almost have to hand out a form of NDA to ensure it doesn't get distributed ahead of schedule.

[Eliana Tamerin]

Not sure if this has yet been stated, but it is pretty important I think it wouldn't hurt to restate it XD.

Software previews... or something like that. I know SMF releases beta's and RC's, but for certain projects, it requires more than that. Like TinyPortal (Though the creator of that is/was a SMF dev ) and SimplePortal which use SMF in many ways is a tough thing to do and can take lots of time for the developers to get it properly working with the new version. Developers might get their projects working with SMF beta's and RC's, but each time a new version is released, a lot has changed and then their product cannot be used by clients for awhile until they have it working with the new version.

Basically, these developers need to be able to see what and how SMF is changing before a version is released. I don't mean SMF tell them first, wait a week or more, then release it. But in some way allow third parties to have some kind of access to know more of what is changing in new versions of SMF in a day to day basis.

Basically what I am saying is kinda like what Microsoft and Apple do... When they are developing the next version of an operating system, they give developers access to SDK's earlier than others, sometimes even giving them the whole operating system so they can test on it and what not. It would be a lot for SMF to do, but you could have some kind of team to do something like that.

So yeah
Sorry if some things didn't make to much sense... I am sitting in a 90 degree room .-.

+1

Beautiful idea. Great for the large and popular mods that often come head to head with the bugfixes and changes in SMF, which causes delays for users, especially with pre-release versions.

[Ensiferous]

If SMF had a quicker release cycle it really wouldn't matter much. SMF has a great platform for notifying administrators of new updates, (although a notice on index wouldn't hurt) coupled with a more modular structure in the future (one can at least dream) SMF can basically update modules with small feature additions or changes instead of having to wait a year for a huge update. That way updates required to mods would be minimal at best, especially if each module provides an API and make as few changes as possible to that.

Giving out early releases would be a band-aid solution and would involve a lot of work with no real gain, IMO it's yet again a question about code structure.