On Wed, Nov 30, 2011 at 11:05 AM, Aaron Bentley <aa...@canonical.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11-11-29 03:29 PM, Robert Collins wrote: >> On Wed, Nov 30, 2011 at 6:41 AM, Aaron Bentley >> <aa...@canonical.com> wrote: >>> I don't think we need participants in that API. I think people >>> would like control over all notifications. So participants can >>> be selected the same way that other recipients are selected. >> >> I agree that people want that control. The issue here is dealing >> with race conditions. >> >> Consider: removing an assignee. You would expect the assignee to >> be notified. But LP no longer knows who the assignee is after they >> are removed. So that knowledge needs to be preserved. > > ISTM that you could subscribe $USER to "relationship changes of $USER" > and then include the user in the event tags.
Pulling on this approach a bit, I think you're saying: - model participants as event tags (assignee:$objid, creator:$objid etc) - have an appropriate default subscription setup for new LP users for our current implicit subscription rules e.g. (if lifeless is my object id) 'lifeless is subscribed to event tag 'assignee:lifeless' I think this is a nice way to approach it. It would allow scoped refinement to such subscriptions, if we have a consistent story around combing wide-generic subscriptions with narrow focused ones. That may require an option on the subscription or something - I don't know :) -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
