Thread:Talk:Echo (Notifications)/Registration with central service/reply (5)

I totally agree. It's the main reason I brought up the question. And to take it a step further, it is very possible to just make the central service and the originating wiki one and the same. Every wiki will come packaged with the notifications system built-in (including the databases and whatnot). The originating wiki will just query its own databases for notifications. And then if you want to add wikis to the farm, we can simply make another entry point, e.g., notify.php or something to that extent, and other wikis will query the original wiki for notification counts.

And as you said, we probably shouldn't store the actual messages, only a count of notifications, similar to how the user_newtalk table currently only store the fact that there is a notification, not the actual talk page message left.

In terms of implementation, I'd imagine this would first involve some sort of types table that stores each event type along with its ID, name, and a page title related to the message if applicable (this is necessary because if a notification occurs on one wiki and the user browses another, the other wiki may not necessarily know where to link the notification). And then there would be a notifications table that would store the wiki name, user ID, type ID, timestamp, expiration timestamp (if applicable), and maybe parameters.

Wikis would register their message types with the originating wiki upon install/upgrade, and no two message types would be allowed to have the same name. Then any time the user requests notifications from a client wiki, the wiki would poll the notifications server, which would respond (either out of memcached or DB if there's a cache miss). As an alternative, we could also have it configured so that the central wiki pushes changes to other wikis, which then cache the results locally, but that would be trading network bandwidth and memcached storage for request latency, which means push notifications would only be enabled for wiki farms with very fast internal networking.