Archived Boards and Threads... > SMF Feedback and Discussion

What can we do to help grow our 3PDs?

<< < (20/23) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page