BuddyPress.org

Okay, as I was thinking about and writing a reply to Andy’s OP, there have been many posts. So, I will post what I have to say first before reading the rest of this thread. I’ll post again if I have anything to say with regards to other people’s comments

First of all, I want to say thank you for starting this thread. This type of discussion is not something that can been done effectively on IRC. Secondly, it’s clear that the trajectory of the referring thread has struck a nerve in you.

My comments were an attempt to start a healthy debate and not meant as a major criticism. Your work on the BuddyPress core is very commendable and much appreciated. So, let me reiterate, as I stated in my first post in that thread, I’m excited with the direction BuddyPress is headed. I believe that v1.2 will be a major, beneficial update to the platform.

The vision that you’ve outlined here helps frame the discussion going forward. Up until now, we, or at least I, did not have a clear idea about your vision. The roadmap is of course only a listing of features. It is not a statement of your design philosophy or design goals. All that the majority of us could discern about your vision (and here I particularly mean developers) was from what we saw in each changeset and a few morsels gleamed from IRC here and there.

With that said, I think this is the most crucial statement:

What I don’t want is for BuddyPress to be limited to high end servers with beautiful caching solutions. In reality, I want this thing to run on cheap hosts where someone can just throw it up there and it doesn’t take the server down.

This is a lofty but worthy goal! In my mind, I look at WPMU and BuddyPress as platforms best utilized on more robust setups. To that end, my ideas, my suggested approaches, have been geared toward a higher-end user. But now that this particular goal of yours has been stated, I have a very clear idea of what guides your BuddyPress design decisions.

Your ideas about the activity stream are interesting.

Rather than creating multiple new tables for each content type, why not just use the activity table but be able to denote different types of content using identifiers or types?

This will require some thought if blog posts, forum posts, and other content types are to be successfully integrated into this vision. I guess for purposes of backend discussion, it might be best to refer to this envisioned table, or set of related tables, as content tables instead of activity tables.

Activity of any type would be recorded in the appropriate content table and thought of as primary content and secondary content. Primary content is the object of the activity—a post (in a blog or forum), a picture (any piece of media), an accepted friendship, etcetera. Secondary content would be any response to the primary content—comments, retweets, etcetera.

As far as proposed schema changes, that all depends on how this vision is charted out. So, perhaps it’s best to figure that out before debating, or even professionally arguing, about DB design.