Future Architecture Request: move topics and posts into core application

[KT Walrus]

As a programmer, I think that if you moved the topics and posts table into the core application and made them available to the other application, the board would be better.

Basically, every app I've installed so far including the various apps that come with IP.Board (forums, members, messenger, blogs, tracker, calendar, gallery), have the equivalent of the topics and posts table. A member's profile has the About Me section (topics), and the profile comments (posts). The messenger has the messages (topics) and replies (posts). The blogs has entries (topics) and comments (posts). The tracker has issues (topics) and comments (posts). The calendar has events (topics) and could easily have comments to events (posts). The gallery has images (topics) and comments (posts).

Every app is likely to have this same basic structure: a single table for posts (so all content posted by members is searchable in a single table and a single table for threads (to describe this content).

Apps would have to have the ability to extend these core thread and post tables with new columns, but they should all be made to agree to populate the common columns when adding, updating, and deleting content. Note that you would need to introduce the concept of class to the core thread and post tables (that is, have a tag/type column and allow extension by adding columns or overriding the common columns for a particular instance of a class object.

The result would be global searchable content and lists (like View New Content) that can show all content ordered or filtered in a more efficient manner to the member. I want to be able to generate a single list of all content posted by a member ordered with the newest content first. I want to visit a community that has blogs/galleries/calendars/forums and just look at a single list of new content. I really don't want to poke around in various tabs to see if anything new has been added. I even want to see calendar events for the current and past days in this single list (so I don't miss birthdays or can see that I missed some community event the day before. Same goes for personal messages. It would be nice if they showed up as well in the new content list (although most members are probably comfortable with viewing the messenger as an online mailbox and don't necessarily gain as much by treating the member's messages as a private forum). Still, for the sake of consistency, I would treat messages as conversations (or threads) which is really what a forum is all about.

I'd love to hear back from you as to whether something might be done along this line in the coming year or so. If not, I might make a pass over the code and do it for myself. The mods would be extensive (although not as bad now that the software is more object oriented.

This is my biggest suggestion for the future.

[Brandon D]

I tweeted the same idea to Matt some time ago when I was working on the comments section of Links System. I believe his response was that abstracting out topics/posts was considered for IPB3 but it didn't make the cut due to time constraints (and, let's face it, abstracting out the core feature of a discussion forum so that it can be efficiently implemented by and properly integrated into other apps isn't exactly the easiest of tasks).

[KT Walrus]

I just want to get this suggestion read by IPS. If it wait until IP.Board 4, that is fine. I won't bother unifying the various app specific thread and post tables for my installation. But, if it will never happen, I may take a day or two and cut this feature in. I don't need to keep compatibility with other apps that I'm not using and I can cut this into the one's that I use in a fairly straight forward manner. All the apps that I have currently installed have their own thread and/or posts table so it might not be that bad for me to implement.

But, if I fork my version of IP.Board (and apps) too much from the IPS maintained ones, I could be making a lot of work for myself when it comes time for me to integrate bug fixes. It is bad enough to manage skin changes. I don't really want to make too many source changes (especially for something that really should be done in the IPS maintained version).

I'm a little surprised that IP.Board 3 didn't integrate this feature in the first place. They didn't even seem to want to change the names of those tables to use the new convention (either ibf_core_topics/ibf_core_posts or ibf_forums_topics/ibf_forums_posts) but I do understand that they probably didn't want to cause third-party modders to have to change too much of their existing mods.

[Matt]

The two biggest obstacles are legacy issues and size issues. No one with more than 500k posts is going to want to run queries to update or move the posts to a new system. It could potentially take hours to complete. Another consideration is size. Some operating systems impose a 4gb limit on a single file. We've had some customers who've hit this problem with the datafile for their posts table. Lumping all 'post' type data into one table will only exacerbate the issue further. You'll also have locking issues if a lot of applications are constantly reading writing to a single large table as well as maintaining indexes required for full text searching.

It's one of those normalization theories that is sound but limited by the back-end software.