On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross <tr...@redhat.com> wrote: > > On 03/05/2013 02:14 PM, Rajith Attapattu wrote: >> >> >> This is a good explanation that we need to put in the docs, as >> Application developers certainly need to know how it behaves. >> If one were to use the current C impl, it certainly gives the >> impression that put() is meant to write messages into your internal >> buffer and send() will actually write it to the wire. >> Unfortunately some applications will depend on this behaviour, even >> though it's not advisable >> >> If we are to change from say #2 to #1 or even #3 we need to release >> note it prominently. >> >> I think the best solution is to make this behaviour configurable, and >> advertise the default very prominently. >> This way application developers will know exactly what they are >> getting instead of us making changes underneath. >> >> Rajith >> > > Making this configurable multiplies the size of the test matrix. Can't we > make this simpler?
I do understand your concern here, but the Java impl already does both #1 and #2 and Rafi wants to do #3 in the future. The old JMS client does something similar. I agree that if we just do option #2 (as you suggest below), then the application can easily do #1 and #3 on top of that. But I'm sure they will like if the library implements those strategies for them and they have the ability to pick a strategy. > To me, this sounds like an I/O facility in which your output lines may never > get sent if you don't call fflush(). This will be a surprise to most > programmers, who rarely use fflush(). I think most programmers would be > happier if "put" caused the messages to be eventually sent and "send" was > used only for blocking until messages were flushed out. > > -Ted >
