V4 Components: Notification Service

Development
1

This is a follow-on to the V4 Architecture article.

The Notification Service provides access to messages.

  • A message has a user as a sender (which includes the possibility of a system user).
  • A message has one or more users (or set of users) as a recipient.
  • A message has a text body.
  • A message may be associated with a game module or game instance.
  • A message may be marked as read or unread.

The purpose of the Notification Service is to notify users of Vassal changes, updates, and releases; module updates; and for notices during asynchronous play, such as alerts that a player’s turn has started.

The Notification Service must support:

  • Posting of a message.
  • Retrieval of a message by id.
  • Querying messages by their properties: sender, timestamp, game module, game instance, read/unread.
  • Possibly full-text search?
  • Possibly replies?

This description suggests a straightforward JSON API to implement it.

1 Like
2

Very useful. Additionally on the client side, it might be worthwhile to have the ability to filter by various attributes. For example, modules I own, game tags I am interested in.

3

I do not envisage that all these ‘messages’ will necessarily be ‘publicly’ available.

Some will be certainly be for general consumption - New version of Vassal available, New version of module X which you have downloaded is available.

Others, like messages attached to a specific Game Instance, I don’t think you should be able to retrieve unless you ‘know’ the uid of the Game Instance (i.e. are holding a seat in that game).

There will also be far too many messages floating around to allow open slather.

This also implies the notification service will require a database backing store to hold the messages, which has significant implications (Sizing, Management, backups, error recovery). These implications also apply to some of the other services we are suggesting e.g. trusted servers providing hidden information management.

1 Like
4

They should be retrievable by their recipients, and possibly by an admin user.

1 Like
5

I would think they should also be retrievable by their senders. Thanks.

6

Now that I think of it, I’m not sure they should have users as senders at all—this is meant to be a notification service, not a general messaging service.

7

Are these notifications something like a messaging service which has channels that you can subscribe to? For instance, these types of use cases:

  • I’d like to subscribe to the VASSAL system game module channel. Tell me about all new modules, updated modules, and obsoleted modules.
  • I’d like to subscribe to the system game instance channel. Tell me about all the game module plays, the start and stop times of all game instances.
  • I’d like to subscribe to the system game module XYZ channel. Tell me about running games and people waiting for games for XYZ.
  • I’d like to subscribe to the system game module XYZ, game instance 123 channel. Tell me about the players for this game instance and all public info about the moves from each player.

Does the original post cover something like this, or is the original post more to be used by a particular game module and instance?