On Wed, Nov 30, 2011 at 8:00 AM, Martin Pool <m...@canonical.com> 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. -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
