Wedge

Quote from nend on April 23rd, 2012, 06:10 PM

How about us that operate and live in the US and decide to ignore the foreign law. I shouldn't be expected to follow by a law that I am in no way bound by, should I?

Except for the fact that US law makers are in the process of an equivalent Federal statute ....

Quote

*edit, this system also helps reduce server load. Hopefully you didn't disable it, the mod IMHO is useless without this system in place because it can bring your site to a slow down. It is hard to remember everything from back then, lol.

Ah you're the original author! You created a great modification and, IMHO, the best of its type I found for SMF.

Changing its index.php file was actually very simple - even for a 61 year old non-programmer like me!

Code: [Select]

    define('SMF', 1);

    // Experimental Optimizer
    define('loadOpt', 1);
   

    // Lets go head and load the settings here.
    require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');

    // Load SMF's compatibility file for unsupported functions.
    if (@version_compare(PHP_VERSION, '5') == -1) {
        require_once($sourcedir . '/Subs-Compat.php');
    }
    //
    // Load Emanuele's 'EU Cookie-checker Modification.
    require_once($sourcedir . '/Subs-EclWarning.php');
   
    // If the user hasn't accepted cookies, get out! We can not go ahead and load SA-Chat
    // because set_session() sets cookies and so potentially does SA-Chat's javascript.
    if (!ecl_authorized_cookies())
        die();
   
    // Okay, cookies can be set so continue.   
    session_start();
    session_cache_limiter('nocache');
   
//<-------------------------------------------------------------------------------   
    // Load the theme
    if (isset($_REQUEST['theme']) && !strstr('..', $_REQUEST['theme']) && is_file('./themes/'.$_REQUEST['theme'].'/template.php') && is_file('./themes/'.$_REQUEST['theme'].'/style.css')) {
        $themeurl = $boardurl.'/sachat/themes/'.$_REQUEST['theme'];
        $themedir = $boarddir.'/sachat/themes/'.$_REQUEST['theme'];
        $thjs = 'theme='.$_REQUEST['theme'].'&';
        require_once($themedir.'/template.php');
    }


All I needed to do was to move the loading of Settings.php and Subs-Compat.php up from below session_start(), then load the Cookie checking code. All your basic logic remains as it was before and now what happens is that if the Cookie authorisation Cookie is not detected, the chat application isn't executed. The load checking and balancing code is still there and fully-operative but only, of course, if cookies are authorised.

With Emanuele's help (he used some kind of analyser on my site) I discovered that PHPSESSID was being set was because I have SA-Chat installed and, for some strange reason, it has its own index.php file. One of the very first things that happens is that there's a call to start_session(). A simple edit was all it took me to prevent the Mod from loading unless cookies had been authorised.

- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So,

1/ Add an id_owner (id_member) field to the membergroups table.

2/ Add an interface for users to create membergroups.

3/ Add more membergroup types. Things like 'hidden' and such are good

4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.

(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.

(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)

So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.

Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...

I'm not going to get into the meat of things here, because there's a lot of things that this impacts on, but I will take care of the issue relating to 3NF.

There are times and places that normalised data can have performance concerns. (And really, 3NF is tame. Wait until you start dealing with 5NF. :niark:) Like everything else, that is.

Now, a lot of my concern about normalising everything is that you end up generating far more rows in a resultset than you need or you start getting more queries, and for information you're loading at certain times, it's going to get hideous.

I actually have an example in SMF for this: board level moderators. They're stored in their own table, and during the board index gathering query, they're actually pulled via join into the main query. Now, on a forum without any board level moderators, it's not a problem. But if you have one board with 3 moderators, that board is returned three times, once for each moderator, which has to be cleaned up in PHP, and that accounts for some of the overhead attached to the board index stuff (which is, indirectly, one of the reasons the sub-board-of-a-sub-board problem occurs).

In that particular case, I'd almost argue that having board moderators would almost be better handled as a comma-separated value stored inline in the board table, precisely because there aren't many of them in most cases.

Getting back to the concern here, separating out friends to another table will give you the proper asynchronous structure you want. But it means that loading the list of friends up front is not cheap, because it means either overloading the first query where mem.* is loaded (which for any number of friends is non trivial), or we add a new query at that point, or we push it into a cache.

That said, we can consider a few alternatives... where exactly do we need to know and care about whether a given user is a friend of ours? Well, for the users online area in the footer, certainly, but with an asynch table we can actually do a join from *that* query and figure it out that way. For the PM area we can do a query as needed there, and so on.

Like everything else, it's a change, but it can bring other changes to balance it out.

Carrying out 500000 iterations

String: `something short`
MD5: 0.34987902641296 seconds
SHA1: 0.48932695388794 seconds
B64: 0.16412401199341 seconds
B64/sstrtr: 0.57090711593628 seconds
B64/str_replace: 0.92343997955322 seconds
sstrtr: 0.41409516334534 seconds
str_replace: 0.85998892784119 seconds

String: `something much much much much much longer that we can use to benchmark these things.`
MD5: 0.48175501823425 seconds
SHA1: 0.70720291137695 seconds
B64: 0.23448801040649 seconds
B64/sstrtr: 0.6997401714325 seconds
B64/str_replace: 1.0725769996643 seconds
sstrtr: 0.48645901679993 seconds
str_replace: 0.88212299346924 seconds

String: `something impossibly and unrealistically long, after longer than the typical cache key will be but just in case it is worth having an idea of relative performance`
MD5: 0.52688503265381 seconds
SHA1: 0.93148612976074 seconds
B64: 0.32354092597961 seconds
B64/sstrtr: 0.91212201118469 seconds
B64/str_replace: 1.3229742050171 seconds
sstrtr: 0.60456418991089 seconds
str_replace: 1.0461859703064 seconds