← Back to team overview

launchpad-dev team mailing list archive

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


On Tue, Nov 29, 2011 at 5:34 AM, curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> wrote:
> 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.

Certainly, reevaluatiing some of our existing UI choices is possible.

I don't believe its needed here though: its no worse than a twitter
page with thousands of followers : show the first hundred or so, allow
click through (non-js) or ajax to investigate them all.

One of our problems in LP is that we don't much in the way of query
optimised schemas - just the main data representing schema. This makes
it hard e.g. we have to check email addresses for validity when
showing 'who will be notified'.