On Mon, Apr 20, 2009 at 11:29 AM, Roman Kalukiewicz <[email protected]> wrote: > OK Claus, I'm somehow convinced, but what would you say about > > sendInOnly() > sendInOut() Yeah and we can have a generic send for the remaining 5% use cases, where you can set the pattern and whatnot.
> > This way there is no problem at all with understanding what it does > and the name is short and clear. Yeah and it also helps bringing the exchange pattern into the light. > > Another thing is those headers that I believe should be in overloaded > signatures and shouldn't be in method names. Yeah that avoid a bit of confusion as well. However the number of overloaded methods might explode based on the combo. But we could reduce it and let people use a processor to setup the exchange before its sent. This gives them 100% control. However that usually requires inlined anonym inner class. Yeah I like your suggestion Roman. Others any thoughts, yet again its now we have the time to mess with the API. > > Roman > > 2009/4/20 Claus Ibsen <[email protected]>: >> On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz >> <[email protected]> wrote: >>> Hello Claus, >>> >>> You asked for thoughts, so here they are ;) >> Great the more the better. This is now you have the chance to >> influence the API before 2.0 is settled. >> So please reply with any thoughts you have. >> The producertemplate is very useful so we want to provide a API that >> intuitive and you can use without being in doubt. >> >>> >>> What about totally different approach, that would be a pattern >>> parameter instead of a method name. Especially that those methods >>> differ only in pattern set on the exchange. >>> >>> In fact I believe the best approach would be to have sendMessage() >>> method that has pattern as a parameter and is overloaded with versions >>> for sending only body, only one header, and a map of headers. Why the >>> method name has to show what parameters already clarify? >> >> I see two/three issues with the combined method approach >> >> 1) >> The method must be delcared to return something. That is a drawback >> for InOnly methods where you can use void. >> This was confusing in 1.x as people would thing that are doing an >> InOut but the have selected a InOnly method but >> in the 1.x API it would still return something, and in some of the >> older 1.x releases it was the IN payload you sent. >> >> And with the void we get help from the compiler if the end users >> things he is doing and InOut and expects an output. >> >> >> 2) >> You have to specify the pattern using an enum and thus you need >> imports and the method parameters get long >> and/or you can use static imports to shorten it. But it all takes time >> to setup in the IDE and well ... it just feels >> like a drag in 95% if the uses cases where you either use InOnly or InOut. >> >> 3) >> We should also consider being similar to the other integration >> projects in this matter. >> >> Spring Integration uses 2 different method signatures. >> Mule as well AFAIR >> >> >> And now we are talking about this API. What about: >> >> 4) >> The API in ProducerTemplate have grown to large IMHO. So I also >> suggest to reduce it and use specialized methods for the 95% use >> cases. >> And the provide a few fallback methods that you can use for the other 5%. >> >> And we should consider not having copies with both String endpointUri >> and Endpoint as the object. >> You can always go from Endpoint -> endpointUri so we should consider >> removing some of the Endpoint variations. >> >> >> >> >> >> >> >>> >>> Romek >>> >>> 2009/4/19 Claus Ibsen <[email protected]>: >>>> Hi >>>> >>>> Actually I think the naming convention should be: >>>> >>>> send = for in only >>>> sendWithHeader >>>> sendWithHeaders >>>> >>>> sendAndReceive = for in out >>>> sendAndReceiveWithHeader >>>> sendAndReceiveWithHeaders >>>> >>>> Its more intuitive than currently >>>> send = for in only >>>> request = for in out >>>> >>>> However what about the "body" method we can do it like >>>> >>>> sendAndReceiveBody >>>> sendAndReceiveBodyWithHeader >>>> sendAndReceiveBodyWithHeaders >>>> >>>> or >>>> >>>> sendBodyAndReceiveWihHeader >>>> sendBodyAndReceiveWithHeaders >>>> >>>> I prefer the former as its sending a body and receving a body. >>>> >>>> >>>> Any thoughts on this, as we still have time to for this API change >>>> before 2.0 is ready for release. >>>> However the clock is ticking!!! >>>> >>>> >>>> >>>> >>>> On Sat, Apr 4, 2009 at 9:20 AM, Claus Ibsen <[email protected]> wrote: >>>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <[email protected]> wrote: >>>>>> The requestBody method makes sense (it requests a body) - but >>>>>> "requestBodyAndHeader" and "requestBodyAndHeaders" etc methods make less >>>>>> sense - because I'm only requesting one thing (the body). >>>>>> >>>>>> maybe "requestBodyWithHeader" makes more sense? for the >>>>>> "sendBodyAndHeader" >>>>>> methods, it makes sense because you are sending two things (the body and >>>>>> the >>>>>> header) >>>>>> >>>>>> although, perhaps I'm just going crazy? >>>>> No it makes sense. You only get the body as reply. >>>>> >>>>> But to make it consistent the sendBodyAndHeader could also be named as >>>>> sendBodyWithHeader. >>>>> >>>>>> >>>>>> Ryan >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> Apache Camel Committer >>>>> >>>>> Open Source Integration: http://fusesource.com >>>>> Blog: http://davsclaus.blogspot.com/ >>>>> Twitter: http://twitter.com/davsclaus >>>>> Apache Camel Reference Card: >>>>> http://refcardz.dzone.com/refcardz/enterprise-integration >>>>> >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> Apache Camel Committer >>>> >>>> Open Source Integration: http://fusesource.com >>>> Blog: http://davsclaus.blogspot.com/ >>>> Twitter: http://twitter.com/davsclaus >>>> Apache Camel Reference Card: >>>> http://refcardz.dzone.com/refcardz/enterprise-integration >>>> >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> Apache Camel Reference Card: >> http://refcardz.dzone.com/refcardz/enterprise-integration >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
