OK, so I've spent a bit more time looking at vB 3.8.7, this time peeking into the DB and it's 158 tables. Yes REALLY. (Mind you, we have 90-odd tables at present, with a few possible casualties in future)
First up, I see a table storing the parsed copies of posts, subdivided by time and images. This is interesting because it means you'd parse_bbc once per post (unless you change settings, but that's its own interesting quirk, they have a maintenance thing for rebuilding it)
Second, the DB does indeed verify what I said before... in the attachment table I see a mediumblob column. It's certainly interesting, not innovative (I have thought of doing it for certain plugins)
Third, we have the choice of postbits, either the two column layout we use - which vB 3.8 claims is *legacy* or there's the full-width poster info with all the other stuff above the post. It's fugly to my eye but I can see the appeal for some. I kind of hope we can pull this off with the template skeleton, or at least either a plugin or a theme can do it, to prove it can be done.
Fourthly, adding views to the view count is not live. It is actually pushed into a separate log and updated hourly, presumably to prevent full table locking on the topics table.
Lastly and most interestingly, threaded conversation. Yes, that feature is in 3.8.7 (but was removed in later versions, not that I'm sure exactly when it was)
So here we have an actual working implementation, let's explore the consequences of it. Firstly, storage of the tree - it is how has been provided for Wedge, i.e. each message tracking its immediate parent.
This is what brings me to the fundamental issue I keep harping on about, retrieving the tree. I'm actually amazed this isn't a serious performance killer looking at it. It's nasty. I can't share it for obvious reasons but it looks like SMF 1 code in some respects - queries with double quoted strings, with variables injected into the query from outside. Including just randomly shoving crap into the SELECT (fields), JOINS and WHERE criteria of the query. It doesn't validate it or anything, it just hands it off to a hook (which is a bare box in admin panel with an eval() around it) and expects the hook to populate global variables. The query takes the form of SELECT post.*, user.* and some other stuff... that would be like us saying SELECT wedge_messages.*, wedge_members.* with some clauses to join them. This is also a query joining... at least 3 tables right there in the query. OUCH.
But it validates something interesting... that fetching the entire tree is not implicitly horrendous. But it does leave a very sour taste in the UI mouth.
vB 3 presents a three-pronged approach to threading. Firstly, we have threaded mode. A largeish subset of the tree is displayed at once, offhand I'm not sure what the rules are but it is a decent subset of the tree around where you are in it. I'd need more time to build a huge tree to assess what its rules really are, but it seems sane. Only one actual message is visible at once and replying to it is of course implicit. Multiquote is fairly important if you want to cross threads of course, but when you press the quote button, whatever you're replying to is the target for the hierarchy.
Then we have hybrid. This is a little curious - again, we get the tree shown to us. But this time when we view an item, we view its children in an otherwise flat style. It's not entire depth, it looks like it descends 5 levels to fetch replies and I don't know how it handles pagination but it folds all those up into chronological order and displays them otherwise flat. It's rather interesting to watch - but the real fun is replying. By default you have to actually select a post to reply to - even before *quick reply* becomes an option (as of course, full reply is no big deal, it just gears up to reply to that one message). The other choice, admin only, is to allow users not to have to do that, which means that by definition any reply is to the end of the thread (so it just replies to the last chain of whatever)
Lastly we have linear. Linear is effectively the same as hybrid - without showing the tree, so it just fetches a subslice of the thread's posts in order. But the real fun part is that by default it still holds the nesting data, so that you still have to pick something to reply to, even if you're not actually using threading because the hierarchy must still be maintained. Here of course every thread would just appear to be one long chain from the top because although we have the capacity to store the parent, we don't have the UI to support that properly, especially with quite reply.
This is the second problem with nested posts, of course (the first being performance).
There is an inherent third problem that comes up, which Kindred mentions every time it's brought out on sm.org, and he's right to a point - it encourages back and forth between individuals rather than addressing the group - but it would likely be useful for some of the discussions that fragment here, actually.
Threaded replies is something we have talked about, something we have indicated that we would be interested in but the nesting aspect always worried me. But if vBulletin does it, it really can't be as bad as I'd feared (or been able to benchmark on my own stuff). What I'm going to do is sleep on it, after all it is bed time, and see how I feel about it all in the morning.
Incidentally, it has provoked a feeling in me. One of the other SMF forks has pursued (and admirably so) a major feature that really appeals to them, though it's something I never wanted to touch beyond a plugin, mostly for support issue reasons... but the fact they're pursuing 'big features' encourages me to want to run wild and pursue big things too.
Posted: February 25th, 2013, 06:22 AM
Also, don't make me look too hard at vB 3's code, is uggggggggleeeeeeeeeee.