Improving SSI - if you use SSI, your opinion will be most desirable here

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Improving SSI - if you use SSI, your opinion will be most desirable here
« Reply #1, 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?
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving SSI - if you use SSI, your opinion will be most desirable here
« Reply #2, 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.

dorje

  • Krabi krabong: the wedge of martial arts. :P
  • Posts: 97
Re: Improving SSI - if you use SSI, your opinion will be most desirable here
« Reply #3, on October 21st, 2011, 09:30 AM »Last edited on October 21st, 2011, 09:37 AM by dorje
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...
Krabi Krabong & programming :D

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Doughboy99

  • Ummm
  • Posts: 1
Re: Improving SSI - if you use SSI, your opinion will be most desirable here
« Reply #5, 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.





Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving SSI - if you use SSI, your opinion will be most desirable here
« Reply #6, 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)