launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 30 November 2011 04:41, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11-11-28 01:49 AM, Robert Collins wrote:
>> Imagine the following API (a strawman, I don't claim its right
>> :)): --------- notify(subject_template, body_template,
>> summary_template, event_tags, topics, subject_tags, participants)
>> """Notify subscribers about an event.
>>
>> 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.
>
>> 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.

I don't know what kind of 'object' Robert had in mind to get
subscribed.  I would have thought you would subscribe a person to an
event.

I think if we do this change it is a good chance to get application
code out of the business of knowing what notifications are delivered
over email vs other means.  It ought to be possible for one message to
be delivered to one user over email, to another over xmpp, and to
another not pushed at all but just shown in the web even if they are
a.

To me that suggests having enough metadata in the notification to let
people set up filter preferences (eg for all of 'bugs' or just for
'bugs.assigned.to_me'), and perhaps also a generic 'importance' level
we can use to set defaults, and perhaps something about the kind of
message in the categories previously discussed - errors, notification,
etc.

-- 
Martin