On 2009-12-01, Remy Blank <[email protected]> wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigB922B00F8E9BE87F390DD041
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> [email protected] wrote:
>> I'd hate to spend time making the old system more like announcer.
>
> That's not what I meant, sorry for being unclear. I understood that the
> lack of a hook in the current notification system was a burden on
> AnnouncerPlugin, and I was suggesting we add that hook (as an extension
> point) to make it easier for you to catch calls from other plugins
> sending notifications. Did I get this wrong?
It makes sense in theory, but not in practice. The way the system
currently works is that plugins extend NotifyEmail. In their
constructor the call NotifyEmail.notify, which calls there email
constructing logic(get_recipients(), send()). Announcer seperates these
steps into
Producer : produces and event
Subscriber : figures out what users to notify of the event
Formatter : creates the content for the event
Distributer : actually create and distribute the email (including
headers)
Most plugins want to do the first three, but not that last one. With
the old system they are very much doing the last one, but worse,
formatting and distributing are mixed together. Also, the notify method
is called directly from the NotifyEmail class. I guess it could be
stubbed out.
But any refactoring would involve breaking backwards compatibility, at
which point I say why bother? Unless we decide we want to keep the
current notification system, in which case the whole argument is moot.
If I'm wrong, I'd be happy to admit it. Any other suggestions?
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
