Add accessors to the Message class

[fedora-infra]

Add accessors to the Message class

[pypingou]

Could it be that the lexer may be used by datagrepper to show the message with a certain high-lighting?

Is subjective used by the conglomerating code in FMN?

[jeremycline]

• title: replaced by summary
• subtitle: replaced by str
• long_form (paragraphs of text about a message): it would be useful for email notifications

Hmm. I was thinking that __str__ would basically be the long-form that you'd normally print to a user. Emails would be summary as the subject, __str__ as the body. IRC would just be summary. Is this enough granularity?

• lexer (pygments lexer that can be applied to the long_form): not sure we want that, it's only implemented for github and scm messages

I vote drop here. If those messages want lexed output, they can add their own method/property to do so.

• link: that would be useful I think (maybe renamed as url? I don't find "link" very clear)

Yes, probably useful for users. +1 on the rename to url, and we can provide a sane default in the base Message.

• icon and secondary_icon: those are usually the app icon and the agent's avatar. They are used, so I think we should keep them, but rename them to app_icon and agent_avatar just to be clearer. (see fedmsg_meta_fedora_infrastructure.fasshim).

Works for me. Again, we can make reasonable defaults and it's a totally opt-in, if you want to make your messages shiny sort of deal.

All the rest I agree with dropping. One last thing is that we should add an importance attribute. Example usage: a successful build could be INFO level, a build failure is ERROR. A failed test would be WARNING or ERROR depending on the test. A passed test is INFO. That way we can set up sane filters for users.

[abompard]

Hmm. I was thinking that __str__ would basically be the long-form that you'd normally print to a user. Emails would be summary as the subject, __str__ as the body. IRC would just be summary. Is this enough granularity?

That would work too. In general title was unused and subtitle was used as a one-line summary, so I think we can drop title, rename the existing subtitle to summary, and the existing long_form to __str__.

Is subjective used by the conglomerating code in FMN?

It doesn't look like it, and anyway since it does not make much sense to receive notification for one's own actions (I know what I just did :-) ), subjective isn't very appropriate there.

I'll prepare a PR.