Simon,
Thanks for your comments. If anyone else has comments,
please send them along!
seeing what we're developing: since this is a core package, I'm
going to check in my development to the OpenACS tree, so you'll
be able to see this live. I tend to commit files quite often. If you
have significant time to help out, I'm happy to get your help. I will
be working on this very actively in the next couple of days.
scalability: I beg to differ - scalability has to be by design, not only
by implementation! Don't downplay your point, I think the issue
you raise is very important. Here's the way I see it, and you can
tell me if you agree:
- we need reliable messaging. Reliability, in every OpenACS
application, has been implemented using transactional control
in the DB. That's why we don't do important data storage in RAM.
Do we really want to start implementing reliable messaging
without transactional control?
- a notification message is kept only as long as it needs to be
kept for delivery purposes. If the message needs to be kept for a
week in the case that someone has only weekly notifications, I
can't imagine storing this message in anything *other* than
permanent storage.
- if there is a huge volume of notifications, it seems highly
unlikely that an application will want to offer weekly notifications:
that would be one extremely long notification at the end of the
week!
Thus, in practice, I think that the only time notification messages
will be kept for a while is when the content of the message
notification is already being stored somewhere else (i.e. a
bboard posting). Thus, in the worst of cases, we are temporarily
doubling our storage requirement. Certainly very noticeable, but I
wouldn't call this a scaling problem.
Delivery, retransmission, and synchronous operation. Simon,
I'm glad we have you on board to tell us about SMS. That's
important stuff. As you mentioned, I think these issues are best
resolved by the specific delivery code. The reliability of the
notifications package *prior* to delivery is ensured by the
RDBMS. The protocol for actually performing the SMS
communication should be left to the SMS package. If you need to
do it synchronously, that's no problem. If you need to do retries,
retransmits, and only delete messages from the queue once
you receive an ack, you can do that. If SMS and another protocol
require the same kind of constructs, then building another
subcomponent might be useful. However, I can't imagine this
being a feature to build into the notifications core. That seems
like too much bloat, especially when email (the biggest current
use of this) doesn't require these features.
The goal of notifications is to do:
- easy targetting of recipients
- batching
- formatting
- centralized preference setting and management for users
I think if we accomplish these things, we've got a solid module
that will motivate usage. I certainly don't want to claim that
notifications will do all SMS stuff flawlessly out of the box. I
expect you guys at OpenMSG to build that extension, since you're
the pros :)
