On 11/28/2011 01:49 AM, Robert Collins wrote: ... > Imagine the following API (a strawman, I don't claim its right :)): > --------- > notify(subject_template, body_template, summary_template, event_tags, > topics, subject_tags, participants) > """Notify subscribers about an event. > > here the three templates are hopefully obvious. > event_tags is a set that would have things like 'bug', 'project', 'branch' > topics is a set of SOA object ids(*) > subject_tags is a set of tags on the object itself. E.g. a bugs tags > would go in subject_tags > participants is a list of subscribables which are direct participants > in the event (and thus should be notified even if the data in LP > doesn't show them as interested). > """
knowing the participant can be costly. We often see timeouts regarding who is subscribed/notified. The subscriptions can change while mail is queued. Bugs can be made private while mail is queued. Answers solved this differently. The notification chooses one or more rules (asker, subscriber, contact) that are queued as jobs. The actual recipients are determined out of proc at the moment the email is sent. A user who changes an email address or is deactivated is handled properly. -- Curtis Hovey http://launchpad.net/~sinzui
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
