Wedge

Public area => The Pub => Topic started by: Arantor on October 21st, 2011, 12:38 AM

Title: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: Arantor on October 21st, 2011, 12:38 AM
SSI is a big beast of a file, and it ends up loading a couple of thousand lines of code, of which a lot of users won't even be using. If, for example, you just do authentication with it, you won't use most of the code there.

Then you have the functions themselves. My personal favourite is ssi_boardNews, which is:
Code: [Select]
ssi_boardNews($board = null, $limit = null, $start = null, $length = null, $output_method = 'echo')

There are some issues with this. For example if you want to get the information back you can't just use (the rather logical):
Code: [Select]
$var = ssi_boardNews($board = 1, $output_method = 'array');

It just doesn't work like that.

Then you have the facilities I built into http://custom.simplemachines.org/mods/index.php?mod=2280 for multiple boards and much more stuff. Which, you'll notice, doesn't one massive function call, you set all the options you want first.

So, I thought... how about we do something similar, but cleaner and able to be much more configurable?


Here's what I'm proposing.

Instead of ssi_boardNews(1); to get the news from board 1, I'm thinking about:

Code: [Select]
$var = new SSI_boardNews();
$var->setBoard(1);
$var->output();

It looks worse, but hear me out. There are a bunch of things that can be achieved with this.

Firstly, we can remove all the SSI functions out of the file and put them somewhere else, so that you only load what you need, and we achieve this with a thing called an autoloader. (Specifically, an SPL one, but don't worry about that.)

So you just request SSI_boardNews() as a class like above, it goes and makes sure the class is available and boom, you can output the board news with it.

But having it set up like that means it's trivial to add different options at will - instead of having a massive function call to set the number of items, the start/length/whatever, you can set all those with separate calls, e.g. to get items 11 to 20 (page 2), the first 500 characters, you would do:

Code: [Select]
$var = new SSI_boardNews();
$var->setBoard(1);
$var->setStart(10); // skipping 10 items, to start at 11, normally you start with the first 1 by skipping 0 items
$var->setLimit(10);
$var->setLength(500);
$var->output();

And there's no set order, no requirement to list all parameters, just the ones you want to change compared to the default. (I could even put the board number into the SSI_boardNews call itself for keeping it small's sake)


Thoughts?


:edit: Interesting side benefit, it would allow you to be able to load individual SSI components as needed without having to load the entire file.
Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: live627 on October 21st, 2011, 01:16 AM
Nice ;) I like iit a lot.

How would it work if a plugin wants to define its own SSI? Would it be a hook as it is now (IIRC), would the autoloader step through the enabled plugins and sniff out the SSI files (expensive), or would there be some kind of listing in the database that plugins can add to for their SSI?
Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: Arantor on October 21st, 2011, 01:21 AM
Right now it's a hook but yeah, that would have to change.

The easiest route I would imagine for it would be to have an array holding the possible paths that will be examined by the autoloader, and have it allow that to be extended.

I am trying to avoid cluttering up the plugin subcaches in the modSettings area so I'm not entirely sure how best to manage it but it is likely a centralised listing providing class name -> file path would be best, because it's cheap to search such a listing and load it directly in the autoloader rather than searching.
Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: dorje on October 21st, 2011, 09:30 AM
I agree... I'm one of those guy using SSI only for autentication (and smf-db related functions). The only function I use is ssi_welcome. :)

About your idea? I think it's a good one, since you can obtain 2 things: faster load[1] and cleaner code!

But I have no experiences with autoloader, so I can't figure out now the real performances... :)

:edit: no, I use parse_bbc also! :eheh:
 1. My experiences with SSI.php teached me that it has an average resource consumption for server that is at least 4 o 5 times greater as other smf pages...
Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: Arantor on October 21st, 2011, 09:38 AM
Well, SSI.php loads a fair amount of SMF before you start, it is essentially loading almost everything you'd need to be able to run any page in SMF - before your custom code even starts.
Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: Doughboy99 on October 21st, 2011, 10:13 AM
Delurk

We use SSI in our Wordpress site to display just recent topics and a list of calendar events by month for the next 12 months to the public. Anything that might speed this up would be most welcome.
We also created an RSS feed of calendar events using SSI as a way of updating an online calendar.




Title: Re: Improving SSI - if you use SSI, your opinion will be most desirable here
Post by: Arantor on October 21st, 2011, 10:15 AM
Bridging Wedge to WordPress will be strongly discouraged for a lot of reasons, not least the fact that Wedge has blog support built in, and that SSI is simply not designed for that kind of integration.

In any case, calendar support is going to be removed from SSI and turned into part of a plugin, though SSI should still be able to make that usable... (that part's a WIP)