Incubator » CB Activity

Object is also called Source and is retrieved with getSource. Maybe it would be better to just serialize the Object and store it with the activity entry? This could result in significantly increasing the storage requirements for the data for little gain. Regardless the function should be renamed to getObject or getSource should also prepare $object and $target. Maybe also add a getTarget.

This basically is to try and make nested streams consistent. If a stream is within a stream it stands to reason its stored rows should reference that. Example as follows.

Standalone Stream: article.42
Embedded Stream: activity.101

With the above the standalone stream is a comment stream for a Joomla article. The embedded stream is a comment stream for an activity entry of an activity stream. This means the embedded entry should ALWAYS prefix its asset. For a profile stream this would mean it would become profile.42.activity.101. If this is maintained throughout ALL usages then the consistency should allow for easily referencing access checks and permissions. Example with CB GroupJive:

CB Gallery: groupjive.group.10
CB Gallery Comments: groupjive.group.10.gallery.photos.30

In short we're treating CB Gallery as streams as well. Basically anything with an Asset should be treated as such. There should be no issues with migrating existing entries as well since we just need to convert activity.%, gallery.%, etc.. to grab their rows asset.

To avoid massive migration queries simply output multiple assets in the streams for B/C. So for example it should become the following.

ROW_ASSET.comment.COMMENT_ID,comment.COMMENT_ID

The primary asset is the first one, but the previously used asset will still be maintained allowing existing entries to display and work as expected but new ones will be stored properly with the new asset.

Migration won't be necessary. The direct assets can still be displayed and likely makes sense. The queries have been improved to guarantee index usage when more than 1 asset is supplied, which completely eliminates the performance issues.

Prefixing the assets so much is starting to negatively bloat them. There needs to be a better way to keep track of this. Currently 'parent' is set for the Stream, which indicates the stream is a child of another stream. This might be entirely sufficient and need no further additions. One option is to pass this 'parent' value to storage in a new Target column.

Example of a prefix nightmare: profile.42.comment.12.comment.13

This would be a comment (reply) to a comment on a post on profile 42. The path makes sense, but this just doesn't bring any benefit. You can parse all of that out by working backwards through objects.

With that said the display and source parsing code all needs improved to accept these scenarios. So for example the ^activity.ACTIVITY_ID parsing needs to accept that there could be pathing before it. This would allow handling prefixed scenarios perfectly fine. This usage is already implemented in and working for CB Gallery.

Parent asset is now just officially a part of the Stream API (e.g. getParentAsset). Parent = Target and Asset = Object. No need to rename everything either. Parent is NOT stored. There's not much reason to do so. If the parent is needed for SQL or other parsing behavior outside of PHP control just prefix it to Asset. This may change at a later time with Parent being stored in the database, but for now it's entirely unnecessary.