On Fri, Sep 30, 2005 at 08:05:05AM -0700, Ned Freed wrote:
After reading this thread and having another go or two at the document,
I now get the idea that "notify" merely enables notifications to be sent
when *other* actions are taken.
I cannot believe this was the intent, but it is it needs to be changed ASAP.
Sounds we all agree in how it should work, but the draft really is
somewhat confusing in describing the notification model.
Also it's not clear if a single notification (one per :id, presumably)
is sent that summarizes all actions that have been taken, or if one
notification must be sent per action (per :id).
Notifications should contains what the action says they should contain.
We may add a site-specific default notification text, if no message is
given.
My personal view is that denotify should be yanked from the specification. I
see no more reason for it than I see for having defileinto or deredirect. (The
last one has an especially nice name, doesn't it?)
I didn't like denotify to begin with, but you do have a strong point
there why. As I said, ":copy" just retains a flag for allowing shorter
code without variables, but denotify works on a set, not on a flag,
and doing so just to avoid variables is silly, as indeed we had to add
cancel actions for all actions otherwise to stay consistent. And if we
did that, all actions had to allow a tag and we needed a generic cancel
action, the whole thing being an extension in itself.
At that point, variables look real attractive. :-)
Yet: Are there any votes against removing denotify?
Michael