← Back to team overview

launchpad-dev team mailing list archive

Re: notifications - an implementation straw man (warning explicit discussion of services follows)


On Wed, Nov 30, 2011 at 8:00 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:

> 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.

People want to be notified; teams want to be notified, robots (e.g.
tarmacs, pqms, jenkins) want to be notified, service layers in LP
(e.g. pubsubhubbub gateways, rabbit gateways) want to be notified. A
generic service doesn't need to know about what the subscriber is,
only that it is, and (depending on how we couple things) how to expand
it into possibly a larger list of subscribers.

> 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.

yes, thats a primary goal.

> 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.

Thats what the various fields in my proposal are for. I don't think a
'importance' vector works well in practice, because there are so many
dimensions folk care about - and because predicting it is so tricky.
Having one or more enumerations, expressable as tags, makes it more
explicit and easier to reason about.