Search Results for 'buddypress'
-
Search Results
-
Cool man, I don’t want anyone to think I only just complain, hehe. I have never been good at sugar coating stuff, and my wife gives me hell all the time about it. Btw, I have a 2 y/o and a pregnant wife, so I reserve the right to be snarky, lol.
Check out my registry for auto-embedding rich media services. I think it could be adapted to work for activity streams, although I guess it would have to be de-PHP5’d
Registry & Service Template Methods
https://plugins.trac.wordpress.org/browser/buddypress-links/tags/0.2-RC1/bp-links-embed-classes.php
Services
https://plugins.trac.wordpress.org/browser/buddypress-links/tags/0.2-RC1/bp-links-embed-services.php
To solve the performance problem, each “service” would need to define a method that denormalizes itself for storage in the table that is queried (it gets hammered). This is very similar to format_activity(), except the abstract activity registry class would define strict rules for the format of data that is returned, then format the output itself from this “cached” denormalized data. We are back to square one with the need to refresh the denormalized data periodically, but I can think of a few ways to lessen the hit. One would be to have a timestamp (or other freshness indicator) column so only records that have changed are refreshed. It would be ideal to refresh the data with a pure SQL query, but then the components would have to provide the SQL to do it, and that would get very messy.
In the end you have an activity stream class interface that basically says… you want to record activity? Ok, extend me and define these methods. You have to return data in exactly this format. Add yourself to my registry, and if you followed directions, I will do all of the heavy lifting for you. Otherwise, get lost.
LMK if any of this sounds good to you, or if we are way off of the same page.
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.
