...
Note that it is better to place discussion points inline, as sub-bullets, than to put them in comments where the context and flow is harder to reconstruct.
- Here's where open issues and problems go. This should be active in the early stages of this work.Do notifications require any concept of proof of receipt? Proof of delivery? Logging of successful and failed delivery attempts, at least to the point of the first relevant server or gateway?
- Do notifications encompass the generation of paper (hardcopy) form letters, such as letters requesting return of loaned items?
- An implementation question: where are the bodies of notification messages - the message texts - maintained? In a set of externally-editable templates (e.g. using Java templating systems such as FreeMarker or Velocity)?
This would offer some advantages - such as permitting straightforward customization, including Internationalization, without requiring code changes - but introduces the risk of malformed or missing templates. (One potential workaround is to have some hard-coded message body text for various notification contexts, in a default language like English, that can't be edited, but override such text if a valid template is found for any of these contexts.)
It may also require the maintenance of generic, functional names for various messaging contexts, with each associated with one (or in the case of Internationalization, one or more) message body templates. This, in turn, might involve a registry of notification message pur