[Jeff Sayre]

… views and on the fly queries are very computationally expensive

Once the initial activity array has been built via query, the array can be appended to with each new reportable activity—as the data is being written to the appropriate table. The only time the system would need to be queried again is during a site reset, or for periodic purposes of clearing the cache. The time interval between cache clearing could be configurable via a Site Admin option.

With fewer writes required—records are written to the component table(s) and not to an activity table as well— performance could actually improve.

[Jeff Sayre]

@Bowe

I understand your befuddlement and I’m sure it’s not caused by esoteric developer speak. It most certainly is due to the fact that obscure T3 references where made by a J3 unit.

[Mike Pratt]

@jjj Yes, you see it that way but I will put forth that you are in the minority. Everyone I come across who classifies themselves as a regular user type thinks that SWA entries are actually the entries themselves. They have no idea that when the comment was originally posted it was also written to the activity cache (the reason for which I totally understand – views and on the fly queries are very computationally expensive)

So that is the issue – given they think that what is being represented in the SWA is the comment itself, they naturally think they are replying TO that comment. But in BP they are not. I know Facebook is not a fair comparison but it’s what are users already know and when they comment in-line on FB they ARE commenting on the original stream… so at a minimum, we’ll have to unlearn that behavior to avoid the “Oh, I didn’t realize remarks”

[Bowe]

I think atleast 10% of my brain just melted by trying to follow this conversation. When JJJ started about Skynet I was doubting if someone put acid in my coffee and by the end of the discussion I still had no clue about what had just happened.

*closes browser and lays down on the ground in fetus position*

[John James Jacoby]

Agreed on all counts. But I see the activity stream as a separate, isolated module of discussion that doesn’t belong in blog comments or post replies. Since that’s my view, the topic of sync’ing them together doesn’t appeal to me. Nevermind the fact that bbPress doesn’t support threaded topics and post replies out of the box in the first place.

Maybe I should just leave this topic and never look back.

[John James Jacoby]

The data is written to a table, the activity_cache table.

[Jeff Sayre]

… it isn’t feasible since the queries it would take to pull that off would be astronomical.

If the data can be written to a table to begin with, and the structure of the written data makes sense, then in theory a query can be designed to accomplish the same outcome without having to write it to a table.

But in practice, since WP uses a sharded DB and not a normalized DB schema, this could be an issue.

… but I think the talking back and forth between the components isn’t really the job of the core to do

Okay, I think I just saw a ghost. That was a scary comment, jjj!

Whereas I agree that it may not be the responsibility of the core to ensure that non-core components successfully talk back and forth with each other or with other core components, it is absolutely the responsibility of the core to ensure that each core component effectively and properly communicates with one another when activated. Every component we have discussed here is a core component.

What you basically just said is the right hand does not need to know what the left hand is doing. In actuality, your right hand may not always need to know what your left hand is doing, but sometimes it is an absolute necessity. The brain takes care of this for us, of course.

BuddyPress’ core needs to take care of monitoring, negotiating, and policing the actions of its core components. As users and developers, we are entirely dependent on the core development team to make sure that happens.

[Paul Wong-Gibbs]

Digging up obscure PHP error messages means you just have to fix them John

[Jeff Sayre]

And if I could reply to only Jeff right now, I would say T_PAAMAYIM_NEKUDOTAYIM

That is why I make sure I have sufficient fiber for breakfast!

[John James Jacoby]

And if I could reply to only Jeff right now, I would say T_PAAMAYIM_NEKUDOTAYIM!

But since I can’t I just forked this conversation in a totally new direction! How’s that for activity.

I think Jeff is right, but it isn’t feasible since the queries it would take to pull that off would be astronomical. The reason this is an activity cache table is because it is where activity is stored in an easier to gather fashion. Maybe cache is the wrong word, but it’s doing what it says by being an easier way to combine other queries into one easy to get, light on its feet query of site wide activity.

The only other solution would be to branch activity comments off into a separate table, but that would require a query for each group of comments, instead of just grabbing all of what’s relevant and dumping it out.

---

Back to the original topic I suppose, but I think the talking back and forth between the components isn’t really the job of the core to do. The activity stream is a functional component of BuddyPress, and BuddyPress can exist without blogs, comments, and forums. In that scenario activity commenting doesn’t matter because there’s nothing to sync with. If someone needs to sync that data, they can make a plugin to do it, just like someone made a plugin to sync bbPress replies to blog posts and vice versa.

[Jeff Sayre]

BP1.2 is shaping up to be a major, beneficial update to the platform. But I do have a small issue with this thread’s topic.

As Mike said several posts above, the current threaded commenting feature of the SWA stream offers nothing more than a “comment about a comment.” I understand what jjj is proposing, but why should we want members to be able to comment about blog comments and forum posts?

Should we later then create a feature that allows members to comment about comments about comments? This is just a rhetorical question, of course.

The SWA table is reporting on activity sitewide. IMO, it should not be a place where new activity is created and stored. If you look at the new table, that is exactly what is happening. There is a new component_action called “activity_comment.” It exists only in the activity table. It is not a reflection of activity that has occurred elsewhere. It is a self-referential, disjointed piece of activity—activity for activity’s sake in essence.

What is the solution?

Well, as Andy has pointed out above, there is limited time before v1.2 comes out. So, at this point, I believe we need to discuss viable and desirable solutions for a future release. Here’s one thought going forward.

I am not a fan of the way that content data is duplicated in the xx_bp_activity_user_activity_cached table. The data already exists in other tables. It is not a good practice to copy it into this table. Yes, I know that that’s what a cache is all about. But a cache is supposed to take place in memory or temporarily on the HD. It is considered temporary storage. It is not written to a physical, permanent table.

Why is this important? Well, since this thread is about the bifurcating of commenting activity, if we ensure that all commenting activity takes place in the original containers—this means in the backend, not in any particular user interface—then we could do away with this table.

This would mean that to obtain the wonderful threaded commenting feature that Andy has implemented for the SWA stream would require that the data be written back to the appropriate tables and properly associated with the original piece of comment datum. The SWA stream would be auto-created from a query, storing the results in an array instead of pulling it from a permanent “cache” table. The array would be updated as needed.

To clarify, be stating that the system would ensure that all commenting activity takes place in the original containers it does not mean that all commenting activity would be forced to occur in the blog or forums screens. With the proper underlying functionality, the system would write the data back to the appropriate table; commenting could occur within any user interface area (like the SWA stream). This is a behind-the-scenes issue, not a user interface issue.

[Mike Pratt]

@jjj …time to start doing pull-ups on your asylum bed frame.

They’re the same but different, and if templated correctly now you have comments about the text of my blog post, and comments about the fact that I posted it.

That really sums it up. Those sites around the web that have elegantly implemented threaded commenting and discussion have created a world where people fork off threads via commenting about that thread or simply add another post to the end of the original stream (how BP works now)

We seem to be getting to some sort of theoretical solution here (I say that ’cause I don’t have to build it

[John James Jacoby]

A great way to finish this off would be with an activity stream widget that was self aware of what content is being loaded on the page. If you’re looking at a blog post, show the activity about that blog post; looking at a forum topic, show the activity about that topic being created; etc…

It will be the Skynet of activity widgets. Self aware… Or maybe just the Terminator widget, always looking for John Connor.

I'll be back, and when I am, I'll be active.

I may have actually lost my mind. haha

[John James Jacoby]

Looks like it was a bad upload of BP. Marking as resolved.

[John James Jacoby]

‘wp_bp_activity_sitewide’ doesn’t exist anymore, not even in the deprecated code. It was dropped pre 1.0 in lieu of having one universal activity stream. A clean 1.1.3 installation shouldn’t have any code looking for those tables.

http://socialpress.co.za/activity/feed works for me.

I’ve created a test account on your website and confirmed that I was able to delete my own activity just fine.

Is it possible this is a conflict with the privacy component?

[r-a-y]

JJJ, that’s what I had in mind (the latter portion of your post)!

[John James Jacoby]

How about we put all of the components that allow activity to hit the stream(s) into an array. Say…

$bp->activity->actions

Then, that array (which already exists) can be altered by a potential administration panel (or future permissions later.) BuddyPress plugins can register themselves as having activity with bp_activity_set_action( ) to which there should be a bp_activity_remove_action() that would add or remove activity abilities to the array such as $bp->activity->actions->comments_enabled

The array will have everything set to true by default. Constants in bp-custom.php or a plugin that makes an admin panel can then set those values to true or false…

bp_activity_get_action()

As long as there’s proper actions in place, plugin authors can sneak in there and append data to comments/forums/posts, whatever, provided everything is available at run time, which it usually is.

Long story short, add another $arg to set if commenting is allowed or not.

Even better…

This would also be a great reason/time to implement an activitymeta table, as it would allow this type of thing to not be core, but plugin territory if someone needs it. Or, that kind of on/off switch could just be in sitemeta and a plugin could block comments on specific activity actions from within the action.bp_blogs_activity_commenting = false

There’s actually a ton of ways this could be done pretty easily.

---

I think a great way to solve this problem would be to have a way for the activity stream item itself to know which post it is pertaining to, and pull that stream and display it on the post either in lieu or or addition to comments. Then people could comment on the activity stream from within the blog post too. Imagine a blog post that said “Comment on this blog post, and see what people are saying about it.” They’re the same but different, and if templated correctly now you have comments about the text of my blog post, and comments about the fact that I posted it.

Same for forum topics and posts. Maybe you use topic/post activity as a way to say “This post is dumb and I think you’re stupid” without ever mucking up the actual forum topic of discussion itself. So you branch out new activity not just with new branches, but whole new ways to discuss that specific activity without interrupting that activity.

Take this forum post. If it had a link to say “Comment on this forum post” and it slid open a post box from within the forum for someone to give me feedback and say “This post is really too long and boring” then from within the forum view you can see each forum post has 3, 4, 20 activity comments on them.

That, is the future of how to integrate the activity stream fully into a website.

…in my opinion(s).

[Andy Peatling]

one addl thought: if we went the route of disabling blog posts and forum replies, what is left to do on the SWA?

Don’t underestimate how much people will use the “What’s new John Doe?” box, since it is sitting there right in front of them. I can imagine that comments will mostly be on those updates.

[r-a-y]

Originally posted by D Cartwright:

I do think we need to have something to feed back comments to the original posting…

I suggested something similar to trackbacks, but for activity comments only. I’d call this “Community reactions” or something similar in that manner.

I guess it could technically be a trackback though…

[Mike Pratt]

@Andy – your recent commit (2189) will certainly give us options while this is sorted out. Appreciate your responsiveness.

[Mike Pratt]

one addl thought: if we went the route of disabling blog posts and forum replies, what is left to do on the SWA? Commenting on the activity that Jack friended Joe? or that someone posted an update. Sort of defeats the purpose of in-line commenting doesn’t it?

[Mike Pratt]

@DJPaul – Ok, then what do you do about the resulting bifurcation of the discussion? I guaranty that users will not universally (nowhere near) know that the comment they leave on the SWA is actually not part of the originating thread which, in effect, renders that comment as a “comment about a comment” and nothing more. There could be some utility in that but it won’t be obvious. Then, we’ll have to take steps to educate users that they are not actually replying to the post itself.

Maybe I’m wrong. maybe having two separately evolving threads isn’t such a big deal. I’m just leery of the forums suffering because everyone is leaving their comments in the SWA instead

[Paul Wong-Gibbs]

I’m not convinced that comments should be fed back to blog posts, as per Andy’s first post on the thread.

[D Cartwright]

Definitely keep the excerpts, though having an easier option to change the length of them would be nice.

I do think we need to have something to feed back comments to the original posting… I’m not sure what would be the best though and I completely agree with the worry of removing the need to visit the original content. As you say, something to worry about for 1.3.

[Andy Peatling]

Also with regards to removing excerpts – that seems as though it would remove a lot of the usefulness of the activity stream. I want to be able to scan the feed and get a taste for the content so I can click and read more of what grabs my interest. You really remove the ability to do that when it’s mostly posting one liners.