launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Nov 30, 2011 at 11:05 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> 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
>> <aaron@xxxxxxxxxxxxx> 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