I think having frequency adjustable by notification request is fairly
important, simply because there are some things that are more
urgent than others. For example, I want to see posts to an
important design thread right away, but I want information about
OpenACS social activities batched daily (assuming no one
organizes a party on 2 hours' notice).
As for overlapping notifications: I don't see any issue with double
notifications if the user so requests it. The "smarts" for not
overlapping notifications - if necessary - should be in the
application itself (forums), not the generic code (notifications).
Although, your argument does point out a flaw in my current
implementation plan, since I've proposed to track whether a user
has received a particular notification, not specifically tied to a
request. Thus, my current implementation plan inherently
removes duplicate notifications... and I'm not sure that's the right
thing (although i can see the argument for this being the magic
bullet).
Anyways, more thought on this is needed!
As for testing and such: I've *just* imported my first pass at the
code. It's by no means fully functional, but the first data model,
PL/SQL, and Tcl APIs are there. It's called notifications in the dev
branch of the OpenACS tree. It's Oracle-only for now, but I will
definitely be porting to PostgreSQL (since I also need it for PG).
