Comment 18 for bug 337394

Mark, we ended up here because I didn't spec the corner case of what should happen when an application tries to replace and append at the same time. But we would have had the same issue if we'd chosen a different protocol to specify appending. For example, if we'd introduced an "append this to THAT message" parameter instead of the "x-canonical-append" hint, it would still be possible for applications to compile whose code included notifications with both that parameter and a a "replaces_id" parameter, so Notify OSD would still have to make the same decision about which to obey. The only difference would have been that it would be harder for applications to use appending (because they'd need to keep track of notification IDs).

I've now updated the spec to specify that replacing overrides appending. <https://wiki.ubuntu.com/NotifyOSD?action=diff&rev2=134&rev1=133> The money quote: "Notify OSD should merge two notifications into a single notification if all of the following are true: ... * the second notification is not specified as a replacement of any other notification."

Separately, as I said in Berlin, I think we should not use the word "update" when talking about notifications themselves. It can mean either of two very different things (appending and replacing), which makes bug reports like this one take longer to clarify.