launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Nov 30, 2011 at 6:41 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> here the three templates are hopefully obvious. event_tags is a set
>> that would have things like 'bug', 'project', 'branch' topics is a
>> set of SOA object ids(*) subject_tags is a set of tags on the
>> object itself. E.g. a bugs tags would go in subject_tags
>> participants is a list of subscribables which are direct
>> participants in the event (and thus should be notified even if the
>> data in LP doesn't show them as interested). """
>
> 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.

Similarly the uploader etc for a source package: direct relationships
that currently imply notification. We could add a subscription as we
add the metadata for the upload, and then (serially) send the event,
and have the service ignore that subscription because the user has a
squelch subscription matching all such per package subscriptions. This
is also potentially racy though, so we'd need to be careful.

>> subscribe(recipient, subscription_tags, event_tags,
>> exclude_event_tags, topics, exclude_topics, subject_tags,
>> exclude_subject_tags) """subscribe an object to an event
>
> I suggest that such objects should describe the recipient and the
> method of notification.  For example, "user abentley via email" or
> "user lifeless via activity wall".  That way, some events might
> trigger emails (or XMPP messages, or tweets...) while others would
> only post on activity walls.

+1.

>> Querying who is subscribed to an object needs to be fast however. A
>> fact table: topic event_tag exclude_event_tag subscriber can give
>> subscription lists for topics very easily, still relying on in-LP
>> expansion of teams. (A topic being e.g. 'bugs for project foo' - a
>> structural subscription).
>
> I'm not sure that doing expansion of teams after determining
> subscribers will give users the control they desire.  I think it might
> be better if subscribing a team generated subscriptions for its
> members, so that they could then adjust them as they desire.

Thats a possibility too. I think both implementations will have hair
around them - and in both cases we certainly want customisation. The
way we customise today is to take the graph-closest subscription for a
user; I think that this works ok, and avoiding some of the hair around
multiple-path-pregenerated-expansions would be net win. Note the 'I
think' - subject to testing etc etc :P

-Rob