<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">(Resending the email that I sent last week but it doesn’t seem to have been sent out actually…)<div class=""><br class=""><div class=""><blockquote type="cite" class="">On 19 Aug 2015, at 21:44, Doug Hellmann <<a href="mailto:doug@doughellmann.com" class="">doug@doughellmann.com</a>> wrote:<br class=""><br class="">Excerpts from Nikolay Makhotkin's message of 2015-08-19 17:16:14 +0300:<br class=""><blockquote type="cite" class="">Hi, Davanum!<br class=""><br class="">Have you already read the thread [1]? It is about acknowledge feature in<br class="">oslo.messaging. Particularly, about the absent of this feature in<br class="">oslo.messaging.<br class=""><br class="">The guys from messaging said that it is very problematically to add that<br class="">kind of feature to oslo.messaging because it does not fit to<br class="">oslo.messaging's approach.<br class=""></blockquote><br class="">The Oslo libraries are meant to evolve as the needs to the applications<br class="">evolve. That process works best when it comes about through<br class="">collaboration between all of us, and the Oslo team has taken on the<br class="">mission of enabling that collaboration. What I'm hearing in this<br class="">request is "the library our community has written doesn't do something<br class="">we want, so rather than work on it with other members of our community<br class="">we want to adopt a different library that is missing different<br class="">features" [2].<br class=""></blockquote><br class="">Doug, yes, I agree. That’s why we decided to start the thread that Nikolay pointed to. To collaborate on that.<br class=""><br class="">My point is the following: we’re not getting rid of oslo.messaging for several reasons (community standard,<br class="">its developers have better vision and expertise at messaging etc.). In any case we’ll have oslo.messaging as one of our <br class="">implementations for rpc layer (by it I mean very Mistral specific interface to distribute tasks over executors and similar).<br class="">And we’re, of course, ready to further work with you on evolving oslo.messaging in the right direction.<br class="">At the same time we still have an idea of implementing our RPC alternatively (w/o oslo.messaging) just for<br class="">purely time reasons, in other words, we want to have that missing feature as soon as possible because our<br class="">customers are already using Mistral in production and it affects them. But once we got all needed in oslo.messaging<br class="">we can get rid of our own implementation at all.<br class=""><br class=""><br class=""><blockquote type="cite" class="">As far as I can tell from reading the thread you linked to, you<br class="">weren't told "no" just that it might be harder than just moving the<br class="">place we send acknowledgments inside the current driver, and we're<br class="">likely to need your help with the implementation. The thread sort<br class="">of died off, so perhaps that wasn't clear.<br class=""></blockquote><br class="">We can try to help with this.<br class=""><br class=""><blockquote type="cite" class="">You have what seems to be a new case -- perhaps its an old case<br class="">that was never being handled properly and everyone actually always<br class="">wanted this, I don't know. Either way, handling that case will<br class="">require a change to the semantics of the library, which means we<br class="">need to be careful about how we do it, but it's not impossible or<br class="">unwanted.<br class=""></blockquote><br class="">Changing semantics seemed to be exactly the main challenge we had in mind.<br class="">It made us think it would hardly be implemented within oslo.messaging any time soon.<br class="">If you’re saying it’s not impossible then it’s good, we need to discuss how it may be<br class="">implemented in a backwards compatible manner.<br class=""><br class=""><blockquote type="cite" class="">However we implement it, we need to ensure backwards compatibility<br class="">for applications relying on the current behavior. For example,<br class="">perhaps the application would pass a flag to the messaging library<br class="">to control whether ACKs are sent before or after processing (we<br class="">don't want that as a configuration option, because it's the application<br class="">developer who needs to handle any differences in behavior, rather<br class="">than the deployer). We should start out with the default behavior<br class="">set to what we have now, and then we can experiment with changing<br class="">it in each application before changing the default in the library.<br class=""><br class="">So, if you're interested in working with us on that, let us know.<br class=""></blockquote><br class="">Yes, we are. What would be the next practical steps that you could suggest?<br class=""><br class="">Thanks<br class=""><br class="">Renat</div></div></body></html>