Merging actions in the timeline based on the subject and/or components.

[Nemesisprime]

I haven't looked into this yet, so I'm prematurely throwing this out there, but in my application I'll begin to get riddled with multiple related actions like:

User 1 commented on Photo A
User 2 commented on Photo A
User 1 uploaded Photo A
User 1 uploaded Photo B

A much more elegant method would be to merge them based on components:

User 1 and User 2 commented on Photo A
User 1 uploaded Photo A and Photo B

Like I said, I haven't gotten into looking on how to implement something like this, but I'm curious of if anyone has any suggestions on methods, ideas, or features related to suggest before I get started.

[brentc]

For the 1.x codebase, I created a filter, CollectingFilter, that did this. Mine only collects direct complements for a specific indirect complement model and the verb 'added', but it could be modified to do what you're doing, probably.

I've collected (and genericised) most of how it works into a gist: https://gist.github.com/brentc/f0303bad7cb8b319856f

The only issue with this implementation, is that filters are applied AFTER pagination occurs, which means your "items per page" will be reduced every time actions are collected. For example, if your per page limit is 10, and you collect 3 of those items into 1 you'll end up only displaying 7 actions on that page. In an extreme case, 9 actions could even be collected into 1, and only 1 action will be displayed.

[stephpy]

Hi, there is imo two solutions:

@brentc solution

*pos : This solution works when you create the 3 actions at different interval *
**con: What @brentc said, number of results can be incorrect

Hacking the "logic" of actions, then you could store an action like that:

Subject => One of users
Verb => uploaded
complement:number_actors => 2
complement:actor_1 => Your user 1
complement:actor_2 => Your user 2

This solution is a bit tricky but you would be able to group each

** con : This solution doest not works when you create the X actions at different interval **

[stephpy]

This behavior is very interesting and it would be cool to support it in bundle :) Thanks to bringing it up.

[Nemesisprime]

Unfortunately, the second option won't suffice. My interactions are being done individually through a rest API, so there'd be no realistic way to implement something of that style across requests.

@brentc's solution is a great start, thanks. I'm still working my way around the inner workings of Timeline, but I'd like to come up with an easily extendable system in the end.

A way to avoid the problem of shrank results is to use infinite scrolling over paged scrolling, which I would suggest for a Timeline anyway.

[thomask]

I'm also very interested in this behaviour!

[stephpy]

Yes @Nemesisprime, the "infinite scrolling" is a good solution, but it'll still be a problem if there is 20 actions to group and you paginate on 10.

But it's complex to make something better ...

May be we could add a system which detect that some actions was filtered and btw RE fetch missing actions ? It should be optional ...

Or add components ManyToMany relations to timeline table and store other components (here users) which comments the photo. Via a POST deploy listener.

[Nemesisprime]

Instead of ALL of the related actions in a timeline merging, they should be merged based on their "chunked" position in timeline. Like:

Jim ate potatoes
Mike ate potatoes
Freddy went skiing
Cara ate potatoes
Jeff commented on Cara
Kasey ate potatoes
Wes commented on Cara

the result of that list split into two "chunks" would similar to:
Jim, Mike, and Cara ate potatoes
Freddy went skiing
Jeff and Wes commented on Cara
Kasey ate potatoes

That way, time still plays a role in the order of results. That would also help if there are illogical breaks (such as 20 items to a group and 10 paginated), they'll look more natural.

[stephpy]

Yes, the time will be important.

For sure it's more complicated to use this solution:

Or add components ManyToMany relations to timeline table and store other components (here users) which comments the photo. Via a POST deploy listener.

But IMHO it's the best way. Because:

• Having a lot of process when deploy action does not impact on user experience.
• Pagination will not be faked

The process will be:

User1 comments Photo1

deployment action to User1, User2, User3 timelines.

User2 comments Photo1

-> deployment action to User1 and User2 timelines
-> delete first timeline entry and add on second entry a reference to User1
-> User 3 does not follow User2, no changes for him.

I had not yet think about how to do that ...

I think to a configuration like that:

group_actions:
    timelimit: 3600 # more than hour and actions will not be grouped
    verbs:
        ate:
            timelimit: ~ #overload root timelimit
            expect_identical_complements: [directComplement, indirectComplement]
        comment:    ~
        # expect_identical_complements: false

Any thought ?

[Nemesisprime]

I like the idea as far as configuration and timeline storage but am no convinced about using time limits as the grouping factor. One of the reasons I would support some sort of auto-grouping would to avoid the problem of having to manually monitor your website's traffic. Active sites could run the risk of grouping everything in the active timeline and slower sites could never even see the grouping while ideally it still should be.

[stephpy]

An other factor could be the interval between actions.

User 1 has in timeline (top is the more recent):

action1: User1 eat potatoes
action2: User1 comment photo1

New action: User2 comment photo1.

We have to group it to action2, btw, fetching X last actions on User1 timeline would be an other solution.

Grouping automatically timelines cannot ensure us to group timelines ideally, and sure, all actions entries will stay stored. Only timelines entries will change.
To avoid a "mass" group on timeline we could add a limit too... No more than X users which comments PHOTO1 else it'll create a new "chunk"

[brentc]

I suspect each project will have it's own conditions for grouping actions and trying to encapsulate a wide array of options in configuration and stock implementations will be problematic.

I think the right approach here is to probably implement a standard means for grouping actions together (either at fetch-time or storage-time, there are pros-and-cons for each), an interface for the grouping class, (e.g. ActionGrouperInterface), and a simple stock implementation (e.g. SequentialActionGrouper extending AbstractActionGrouper).

Provide a simple way for developers to extend the grouping class with their own logic. (e.g. AbstractActionGrouper::shouldGroup($action, $timeline) or perhaps an event base system ActionGroupingEvent::PRE_GROUP, ::GROUP_PASS, ::POST_GROUP)

This should help prevent over-designing the feature and painting developers into a corner with the provided implementation, and should allow developers to provide their own logic based on their unique, concrete action/component implementations.

[stephpy]

+1, you are right.

[thomask]

Sounds great!

[Nemesisprime]

@brentc - Something like this is the most flexible and more in the area I would like to go, so I agree. It seems like doing this during fetch time would be the best solution as well, as we have the most complete set of information about the timeline to base our custom groups on, and we don't have to worry about a failure during the creation/modification of actions when performing an action.

Superficially, perhaps we could use another phrase instead of "grouping". AbstractActionConstraint or AbstractActionCongregator sounds more appropriate.

[brentc]

ActionAggregator?