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

I agree with brion. Event registration should not be something dynamic where publishers register their events at startup because, as aforementioned, MediaWiki doesn't really have a "startup". I would suggest the following: store a list of events for the service in a database table; have wiki-specific configuration variables store what types of notifications each wiki serves; and have a maintenance script similar to update.php for databases that reads the configuration and updates the central service.

Thinking in the context of the whole shebang scenario where we have numerous wikis running, all of which linked to a central notification service, I think the proposed solution is pretty reasonable. The only thing I'm a little confused about is how retrieval of notifications is working. From what it sounds, the user is going directly to the notification service, i.e., the user's browser is contacting the notification service's API, retrieving all notifications, and displaying them across all wikis. How exactly would this work out so that clients do not have to poll the service every time they go on a different wiki. There'd need to be a way for the client to store notifications so that they show on all wikis.

My other concern is for most wikis out there that are not farms with massive requirements for centralized notifications. Is it really necessary and/or efficient to have a separate notification service running for a single wiki?

EDIT:

Actually, I though of something for the latter concern. It is possible to set up the system so that for single wiki installations the wiki can just keep all the database tables the service would normally use within the local database and access them directly.