camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
Date Mon, 20 Apr 2009 09:35:48 GMT
On Mon, Apr 20, 2009 at 11:29 AM, Roman Kalukiewicz
<roman.kalukiewicz@gmail.com> 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 <claus.ibsen@gmail.com>:
>> On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz
>> <roman.kalukiewicz@gmail.com> 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 <claus.ibsen@gmail.com>:
>>>> 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 <claus.ibsen@gmail.com>
wrote:
>>>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ryebrye@gmail.com>
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

Mime
View raw message