<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 September 2016 at 06:52, Ken Giusti <span dir="ltr"><<a target="_blank" href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-HOEnZb"><div class="gmail-h5">On Wed, Aug 31, 2016 at 3:30 PM, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>> wrote:</div></div></blockquote><span class="gmail-">> > I have opinions about other patterns we could use, but I don't want to push</span><br><span class="gmail-"></span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
> my solutions here, I want to see if this is really as much of a problem as<br>
> it looks and if people concur with my summary above.  However, the right<br>
> approach is most definitely to create a new and more fitting set of oslo<br>
> interfaces for communication patterns, and then to encourage people to move<br>
> to the new ones from the old.  (Whether RabbitMQ is involved is neither here<br>
> nor there, as this is really a question of Oslo APIs, not their<br>
> implementation.)<br>
><br>
<br>
</span>Hmmmmmm... maybe.   Message bus technology is varied, and so is it's<br>
behavior.  There are brokerless, point-to-point backends supported by<br>
oslo.messaging [1],[2] which will exhibit different<br>
capabilities/behaviors from the traditional broker-based<br>
store-and-forward backend (e.g. message acking end-to-end vs to the<br>
intermediary).<br></blockquote><div></div><div><br></div><div>The important thing is that you shouldn't have to look behind the curtain.  We can offer APIs that are driven by the implementation (designed for test, and trivial to implement correctly given handy open source projects we know and trust) and the choice of design will therefore be dependent on the backend mechanisms we consider for use to implement the API.  APIs are always a point of negotiation between what the caller needs and what can be implemented in a practical amount of time.  But *I do not care* whether you're using rabbits or carrier pigeons just so long as what you have documented that the API promises me is actually true.  I *do not expect* to have to read RabbitMQ ior AMQP documentation to work out what behaviour I should expect for my messaging.  And its behaviour should be consistent if I have a choice of messaging backends.<br><br>
> All the more reason to have explicit delivery guarantees and well<br>
> understood failure scenarios defined by the API.<br><br>And on this point we totally agree.<br><br>I think the point of an API is to subdivide who carries which responsibilities - the caller for handling exceptional cases and the implementer for having predictable behaviour.  Documentation is the means of agreement.<br><br></div><div>Sorry to state basic good practice - I'm sure we do all accept that this is good behaviour - but with a component that's this central to what we do and so frequently used by so many people I think it's worth reiterating.<br></div><div>-- <br></div><div>Ian.<br></div></div></div></div>