Discussion

Notifiers vs. Users

I assume there is going to need to be an administration section at some point; at a minimum, admins will need to be able to add/remove notifiers that can connect to the hub and manage their auth credentials. This leads to the question of whether notifiers should remain distinct from users or whether they should be treated as users with a different set of roles.

Early in the implementation phase, notifiers will look very similar to users as they will retain a username and password; later on, I would expect notifiers to shed their username and password and be identified and authenticated by either an API key or a SSL certificate. With this in mind, maintaining separation makes sense.

DH:

I generally agree with this approach, with the nuance that this first implementation is going to be one or at most 2 notifiers. The second one, if needed, would likely be on the same machine, and thus be what we imagine is an edge case. So no need to design Notifiers too deeply, until we have more use cases.

Message Terminology

The words program, template and message seemed a bit ambiguous. A template wasn't really a template, it couldn't be evaluated. A message sounds like it would contain the contents of what was being sent. I believe the following terminology works better:

• Message Stream: A series of messages that will be delivered over time (i.e. a data stream). It is also used in context of separation or grouping (i.e. education streaming).
• Message: The message that will actually be sent out.
• Notification: A notification is received from the notifier, specifying the message to send and how to deliver it.

I have yet to update the overview page to reflect these changes in terminology and will probably wait until after the first iteration of development is complete. At that time I will update the overview to reflect what was actually implemented (documentation) as opposed to what should be implemented (specification).