I also installed one new dependency: a helper library that makes it
easier to read and write cookies, given that there are no helper methods
for these purposes in the PSR-7 standard.
This required some interface changes (mostly changing Laravel's or
Symfony's request and response classes to those of Zend's Diactoros.
Some smaller changes to the execution flow in a few of the abstract
action base classes, but nothing substantial.
Note: The request and response classes are immutable, so we usually
need to return new instances after modifying the old ones.
This will be able to dispatch PSR-7-style requests to any callback
that returns a proper response object.
Largely based on my original work for FluxBB 2.0.
Originally the user activity feed was implemented using UNIONs. I was
looking at make an API to add activity “sources”, or extra UNION
queries (select from posts, mentions, etc.) but quickly realised that
this is too slow and there’s no way to make it scale.
So I’ve implemented an API which is very similar to how notifications
work (see previous commit). The `activity` table is an aggregation of
stuff that happens, and it’s kept in sync by an ActivitySyncer which is
used whenever a post it created/edited/deleted, a user is
mentioned/unmentioned, etc.
Again, the API is very simple (see Core\Activity\PostedActivity +
Core\Handlers\Events\UserActivitySyncer)
It turns out that the idea of “sending” a notification is flawed. (What
happens if the notification subject is deleted shortly after? The
notified user would end up with a dud notification which would be
confusing. What about if a post is edited to mention an extra user? If
you sent out notifications, the users who’ve already been mentioned
would get a duplicate notification.)
Instead, I’ve introduced the idea of notification “syncing”. Whenever a
change is made to a piece of data (e.g. a post is created, edited, or
deleted), you make a common notification and “sync” it to a set of
users. The users who’ve received this notification before won’t get it
again. It will be sent out to new users, and hidden from users who’ve
received it before but are no longer recipients (e.g. users who’ve been
“unmentioned” in a post).
To keep track of this, we use the existing notifications database
table, with an added `is_deleted` column. The syncing/diffing is
handled all behind the scenes; the API is extremely simple (see
Core\Notifications\DiscussionRenamedNotification +
Core\Events\Handlers\DiscussionRenamedNotifier)
For now I’ve chucked it on Flarum\Core as a static method, but
ultimately I think we will need a ConfigRepository abstraction (whether
it replaces or sits underneath the Flarum\Core static method I’m not
sure).
Also starting to think about multisite scenarios, I think this is
important. The Forum model could actually end up with a database table
behind it, and each forum would have its own config settings? Haven’t
really thought about it too hard yet…
