launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08523
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'.
-Rob
References