Ben,
Completely agree that somehting like this is necessary. A single, simple mechanism for delivering notifications.
I'm also pleased to see you're taking other messaging forms into consideration (even if not really supported) such as SMS and IM. Given that these are fast becoming de-facto text standards its vital the OACS has this in it toolkit. Interestingly SMS usage in the UK is now higher than email (apparently ?)...
I'd very much appreciate any early views of what your developing, as we may well be able to contribute in some extensions for SMS and so forth.
However, I'm not entirely convinced by the proposed development. Don't get me wrong cos I can't really think of an alternative, but my gut feeling is that this approach (tabled storage based messaging) might have some issues of scale. One of the biggest headaches we have had in the past is the ability of large volumes of email to swamp the performance of the system.
I know I'm largely discussing implementation here rather than design, but it my pet bugbear. Whatever solution is adopted would make me feel much happier if it put performance and volume at the top of its list.
Also, what about serialisation of messages? You seem to be tacitly assuming that messages are delivered in asynchronous fashion. Is there any case for offering some form of serialised delivery?
I'm thinking of a specific situation (and yes, its cellular phones again). When connecting to some systems (SMSC in particular) the general protocol forces a serialised, acknowledgement based interaction. It therefore becomes important for us to serialise.
So, I guess the next thing you;d say is, well that doesn't really belong in this package, but rather whatever handles SMS delivery.. True I suppose, but I don't think this can be entirely limited to SMS.
In summary then, I personally think some kind of facility to support ordering and queueing might be considered.
And does the same point apply to message delivery and re-transmission? Should this package offer that?
Just a few thoughts. I agree with your general theme Ben, in that I too think packages should be simple building blocks, but the danger is that if they are too simple, or funtionaly thin, then the overhead of learning/deploying them to acheive an overall goal becomes onerous and people will favour custom, ns_sendmail style approaches.
For example, the original Spam package, although never completely finished, was a good example of simple function, small package. However given that it did so little, it was almost never worth using it. Far easier to implement direct.
Cheers
Simon
