On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming <[email protected]> wrote: > On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu <[email protected]>wrote: > >> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross <[email protected]> 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. >> > > I don't see why we'd make this configurable. All three options actually > fit the same general semantics. Even if you're optimistically trying to > transmit every single time put is called it's entirely possible for the > socket to be blocked every single time you try. If this were to happen the > implementation of #1 would appear to behave precisely the same as #2 > behaves. > > In other words if you're coding correctly against the API you can't assume > that put will or won't have transmitted anything regardless of which > strategy is used internally. >
I agree with you. You make a very good point. Perhaps we should explicitly make that clear in our docs to avoid applications written against wrong assumptions. Rajith > --Rafael
