BuddyPress.org

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.

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!

… 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.

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.

… 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.

I’ll say this from a user’s perspective. Not programmer.

I want everything as a stream on one page. It’s great if things are categorised as forums, groups, wire and all. But still, I just want to write something in a box in a simple way. This either goes in reply to something or not. I want to encourage my users to engage. I’ve found this to be true with “activity streaming” but not so much with forums or blogs.

I’ve got a small community. Like it will max out at 1000 members. And about 10-20% active ones. To us it will be useful with one stream and to use that mostly. You guys with 10.000 members will probably not have an efficient activity stream.

Let’s make it moddable. It is not a one size fits all.