<h3>Notifications
</h3>The notification package is well documented. Any package can be notification enabled. Thus we can have systems with incredible traffic. Since the notification message is identical for all suscribers logging a single message seems the best.
The problem is that a generic tracking package won't be able to resolve the actual subscribers later on. Also since notification requests can be deleted we don't have the means to reconstruct who was a subscriber at the time the email was sent out. To fix this is simple. Instead of deleting entries from notification_requests we could add two more columns like creation_time and deactivation_time or something. Adding a new request for the same object would deactivate an existing project as does removing a subscription to an object. What do you think?
I prefer to log every single email in favour to a more generic mail-tracking package. We can find ways to archive old logs to prevent the logging table from increasing to much.
Like bulk-mail, notifications doesn't provide a package_id to acs_mail_lite_queue. We need to fix that. I would suggest that we take the package_id of the package that caused the notification.
<h3>ACS Mail Lite (revisited 3)
</h3>The columns to_addr, from_addr and body in acs_mail_lite_queue create strong restrictions on reuse in favor of simplicity:
to_addr - stores the sender's email instead of a valid user_id. This allows any email address as the sender. Why should we allow that?from_addr - stores a TCL list that contains the recipients name, email and user id. Shouldn't the user_id suffice?body can literally contain anything that is text. While bulk-mail and mailing-lists simply contain the message text notifications stores the raw email body. Wouldn't a mapping table form content to email be better?
