← Back to team overview

launchpad-dev team mailing list archive

Re: notifications - an implementation straw man (warning explicit discussion of services follows)


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

Attachment: signature.asc
Description: OpenPGP digital signature

Follow ups