On Tue, Nov 29, 2011 at 5:34 AM, curtis Hovey <curtis.ho...@canonical.com> 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'. -Rob _______________________________________________ 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
