launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 1 December 2011 02:16, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:

> btw, I think topics might be better as a mapping, so that we can
> distinguish between two objects of the same type with different roles.
>
> notify("proposal created", "proposal created", "proposal
> created",['merge-proposal', 'add-relationship', 'add-reviewer'],
> {"source_branch": 'Branch:12', "target_branch": 'Branch:10',
> "proposal": "BranchMergeProposal:25"}, [])

I agree, representing it as a dict rather than collapsing them in to
strings sounds better.  (Maybe I am getting a bit bikesheddy for a
strawman.)

So it seems like you would want

  notify(subject_info = {subject: "https://launchpad.net/+mergeproposal/23";,
subject_type: "https://schema.launchpad.net/CodeReview"; },
        event_info = { add_reviewer: True, add_relationship: True },
        participants = { requested_by: "https://launchpad.net/~mbp/";,
requested: "https://launchpad.net/~gz"; })

I do like Robert's approach of separating out attributes about the
subject, the event, and the participants.

> It seems like it would be nice if we didn't have to specify both
> summary and subject.
>
> Also, what are subject_template, body_template and summary_template?
> HTML?  MIME?

>> notify(subject_template, body_template, summary_template, event_tags, topics, subject_tags, participants)

I was thinking about this too: who is responsible for turning the
structured notification into html or text?  It could be the sender,
the notification framework, or the notification endpoint (that sends
mail or shows it in the web or whatever).  Passing a template that is
necessarily specific to a particular format, but that needs extra work
to be expanded, seems suboptimal.

Emphasizing the templates is likely to make consumers match on
template, when I guess we really want them to match on the structured
information.

-- 
Martin