Comment by lisper
> You are especially well-answered here
I don't see anything there that is at odds with anything I have said. All I see there is a restatement of my position.
> One reason the delivery / processing distinction exists because very often the application needs to atomically...
Yes. Do you really think I did not already know that?
> Thus, the application needs to deal with multiple delivery.
That depends on your requirements. What does that have to do with the possibility or impossibility of exactly-once delivery?
> Imagine a "subtract $5 from my bank account" message with no ID on the message itself
I have never denied that you can invent scenarios that will fail. I explicitly said that exactly-once delivery is likely not what you want. What does that have to do with whether or not it is possible?
> Yes. Do you really think I did not already know that?
Well, if the application and this mythical higher-level thing have to do things atomically and be tightly wed, but you're insistent on calling them different entities so that you can win an internet argument that the second one is not getting duplicate "deliveries" ... then that's honestly kind of sad.
The literature has used the term "delivery" like this basically 100% of the time for the past 20 years, and the majority of the time somewhere else. You can argue that your definition makes sense to you, but when everyone else uses the term the other way it's not helpful. Anyone can choose to define words differently from everyone else and then try to lawyer it out, but it's not likely to be useful or accepted.