-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14.11.2012 23:59, Peter Suter wrote: > On 14.11.2012 20:53, Steffen Hoffmann wrote: >> I know of Peter even asking about need for >> support to do things on the AnnouncerPlugin to TracNotification effort, >> but this happened some months ago. > > (15 months!?)
Really? I didn't look it up by now. Amazing, how time passed by. However, my note on your request meant, that I've been sorry for a possibly missed chance. Even better, that you're obviously still interested in working with notification code. > As Remy hinted at, the existence of AnnouncerPlugin and the integration > proposal seems to paralyse development on TracNotification. > Improving the existing system is not only wasted effort, it also makes > replacing it harder and less urgent. So improving the current system is > counter-productive if your real goal is integrating Announcer. :-/ > > To me it seems really unfortunate that Announcer and TracNotification > are so separate, incompatible, and (until recently) kind of dead. So a > few weeks ago I started working again on a more concrete, piece-by-piece > integration proposal. This has been put on hold for now, also because I > noticed you heavily hacking on Announcer again! Incompatible? Dunno, but I remember the sentence from the AnnouncerPlugin wiki page, that for moving from TracNotification to Announcer one may rename [notification] to [announcer] and go from there. So it was meant with some compatibility in mind, at least initially. I've not done a side-by-side feature and option comparison by now, although this may be required for success of the replacement proposal. > But since this topic is coming up now, here's a short overview of my idea: > > 1) Deprecate the old "high-level" system, don't heavily change or > integrate it with new functionality. But keep the "low-level" code and > configuration. > > 2) Dissect Announcer into topical parts. So far I identified: > * Extension API for Mail/Distribion > * Subscription DB & extension API, and "old" ticket subscriptions > * Modular preference pages > * New ticket subscriptions (Joinable ticket groups and components) > * Permission filters > * HTML emails > * Wiki notifications > * Attachment notifications > * Watchable resources > * Background delivery thread > * SMTP-over-SSL > * GPG encryption > > 3) Start integrating one of these and see how that is going. Interesting approach. > (Some of those parts could/should possibly remain plugins forever.) So AnnouncerPlugin would be reduced to stuff, that lives in announcer/opt now. > But as I said, that was before you revived work on AnnouncerPlugin. > > What would be your preferred way forward? I meant to bring Announcer into good shape, that would qualify for inclusion, after current options and critical parts of the TracNotification API had been mirrored. Your suggestion to patch essential parts of current Announcer infrastructure into existing TracNotification looks like a valid alternative. Certainly * multiple transport options * subscription model * flexible user preferences are the core of Announcer. For watching individual resources WatchlistPlugin may actually be a better candidate. At least I've been looking for a way to rather integrate/replace that part in Announcer with WatchlistPlugin integration, because it's maintainer did a a good job on the web-UI that I didn't want to re-invent. Finally crypto functionality for notification is actually rather high on my list, because I need that. But this will be totally reworked and based on CryptoPlugin infrastructure. I'm sure, that especially this code should change into a decorator (provided we'll make decorators ordered extensions) and will remain in a plugin, because it's still far from common stuff and real-world applications rarely care for privacy and true confidentiality. I know, this sounds odd, even more in business context, but I know that most statements about data protection are vapor when it comes to practical execution. Security comes at a price, that even many businesses are not willing to pay today. So only very security conscientious folks do signing and encryption on a regular base. With ease of use this may change over time. Or with more privacy breaches, or a combination of both. At least I'll contribute code to make this happen for Trac applications, as far as users and admins will care. I'm not determined about the best approach for the aforementioned Announcer proposal yet. Actually I'm looking forward to reactions from other developers about their view and vision for bringing in Announcer features and more to Trac. Steffen Hoffmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCn7wUACgkQ31DJeiZFuHdA8wCgxtiEGfndFGlBoNd7lTznjffR Vy4AoOipkIzBoi4xTcP6lRtSNdk8cjwe =cUVR -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en.
