Floating topics
Blogs! »

Nao

  • Dadman with a boy
  • Posts: 16,079
Floating topics
« on May 11th, 2011, 03:48 PM »
Area: Miscellaneous
Feature: Floating topics
Developer: Nao (main?)
Target: everyone
Status: 10% (nothing implemented in the code; planned feature, please discuss your preferences.)
Comment:

This is one of the first features I considered for Wedge (and possibly one of the things that made me want to build Wedge at all), and unfortunately so far the only one I haven't done anything on, because we need to implement blogs and other details before we can even get started on it, so it probably won't be in the public alphas -- it may not even be in the final 1.0 release. I'm actually taking a minor risk by revealing this feature before it's even implemented, because it's likely to 'inspire' the competition. But on the other hand, I'd for one wouldn't mind seeing that in other forum systems.

Basically, the idea is that topics in Wedge are not just reserved for boards. A topic can be a blog post. It can be a media item. It can even be a profile. These special places can then benefit from some of the topic features, such as commenting on them.

So, topics get a 'type' field that represents whatever they are (profile page, blog post...), and allows Wedge to filter them out when showing only a specific type of topic. Users get to comment on floating topics, and their posts can be searched through the regular search engine, read through 'Unread posts', anything you could think of.

Re: Floating topics
« Reply #1, on May 11th, 2011, 04:37 PM »
* DoctorMalboro takes notes of it and send it to VB :P



Re: Floating topics
« Reply #4, on June 1st, 2011, 08:07 PM »
There have been internal discussions recently, that pretty much pushed this to the bottom half of my to-do list, because some in the team think it's not necessary to store everything into the same place and it can be done differently. I tend to disagree with this, though, so it may not be in the first alpha at all... :^^;:

Re: Floating topics
« Reply #5, on June 3rd, 2011, 06:30 PM »
I think this is a good idea, too. I almost missed your post because I misunderstood the subject "floating topics". This is really a generalization of the idea that a msg_id can belong to a topic, a reply, a blog post or blog comment.  It could also belong to a portal article, or an item associated with any other kind of thing we could think of bolting onto a simple website machine.

Will it require overhauling data structures, tables, and "business logic" on how items are retrieved? Either the topic_id and board_id columns will be generalized, or else (horrors) we go to third-normal form and lose optimization?

Re: Floating topics
« Reply #6, on June 4th, 2011, 11:11 AM »
Quote from AngelinaBelle on June 3rd, 2011, 06:30 PM
This is really a generalization of the idea that a msg_id can belong to a topic, a reply, a blog post or blog comment.
Yes and no.
I think it would be a strain on performance if any 'virtual object' could be a floating topic.
So, an id_msg won't be floating by itself -- only a topic can be floating.
If you mean by that that we should store the parent id_msg for any message, this can be done independently -- and is something I'm considering to do, although it wouldn't be used in Wedge at all since I've long given up on nested threads (I discussed it countless times on sm.org and here I believe. I had an implementation and all. Even Wedge.org keeps storing the parent ID I believe...)
Quote
It could also belong to a portal article, or an item associated with any other kind of thing we could think of bolting onto a simple website machine.
Pretty much.
Now, what matters here is that, not only can the wedge_messages table be thrust into any floating element, but we can also add other items to benefit them. Like/dislike, tags, and custom fields come to mind. We'd... Just need to store the wedge_type (or something like that) for the extra entries, just in case we need to filter the entries by wedge type.
Quote
Will it require overhauling data structures, tables, and "business logic" on how items are retrieved?
I don't really see how. It's just a matter of adding an extra field with proper indexing ;)
Maybe we'll simply rename some fields internally -- although it can be done without, after all I don't mind the idea that a 'topic' can be a 'media item'... It's a topic of discussion after all. Anyway!
Quote
Either the topic_id and board_id columns will be generalized, or else (horrors) we go to third-normal form and lose optimization?
Can you elaborate on this?

Re: Floating topics
« Reply #7, on June 4th, 2011, 01:34 PM »
*rolls eyes* The reasons Unknown created SMF's structure to not use 3NF (using that bastardisation of comma separated values in place of actual table joins etc.) are long since out of date. Back in MySQL 3.x times, it made a difference, but with the advancements made in the quite numerous years since then, there is no practical reason not to move closer to 3NF.

I wouldn't necessarily pile entirely to 3NF, since there are some reasons why you might, for example when you explicitly need to handle orphan cases (messages without a valid author, for example, where you store the data in-row rather than referencing an entity) but certainly a move closer to 3NF is on the cards. Some of this work has already been carried out, in fact.

Re: Floating topics
« Reply #8, on June 4th, 2011, 02:24 PM »
And in that respect, Wedge will have way more tables than SMF ;)

Re: Floating topics
« Reply #9, on June 4th, 2011, 02:28 PM »
*nods* Having lots of tables and proper relationships isn't the bane of performance it used to be, especially now that InnoDB is in the core of MySQL and is default in 5.5, wherein it is a lot more performant on handling such things.

Incidentally it will actually solve a few fringe bugs in the core...

Re: Floating topics
« Reply #10, on June 4th, 2011, 03:08 PM »
I was always sure joins were faster than comma crap in all versions of Mysql?

Re: Floating topics
« Reply #11, on June 4th, 2011, 03:58 PM »
They are, assuming memory isn't an issue. It used to be the case that the overhead of FIND_IN_SET outperformed joins on the typical caseload of a forum, especially on shared servers because machines didn't generally have the RAM to cope with everything in memory for joining when you get massive table sets as the result (where you end up multiplying rows because you're trying to keep as few queries to the server as possible, only to end up making stinking huge queries)