Hi,
>
> On 7/7/11 5:28 AM, Sergey Beryozkin wrote:
>> I spent some time yesterday analyzing the current API draft on the wiki and Bill's version,
>>
>> This is actually pretty close, definitely invocation.get() being the last thing to call is good, but Invocation is just a wrong term, and
>> the current version breaks the idea of Invocation being fully initialized for it to be used by batch processors, i.e, you can't call
>> Invocation.invoke() without setting the right method name and generic processors have no idea about it.
>>
>
> NOt sure I'm understanding you. If you include an invoke() within
> Invocation, it can be used by batch processors.
>
what HTTP method will they use ? I guess a user will set that explicitly
on Invocation, using setMethod(method), before passing it in, but that
won't work in a case where Client references are injected given that
client.request().setMethod("GET").invoke won't be thread safe
>> Besides we still have a duplication between Link& HttpRequest as far as setting pathParams/etc is concerned which is a good sign that Link (which is misnamed IMHO) needs to extend HttpRequest and do what Invocation does now, in Bill's version, with Invocation and AsyncInvocation being already initialized, if used...Summarizing it in the diff email
>>
>
> I could agree that having pathParam, etc. on Link might not be a good
> idea, but merging Link and HttpRequest is not a good idea. Link is a
> reusable reference that might generate different requests. It might be
> backed by a URI template, it might not.
>
> You make invocations on a Link. Links are not invocations, nor do links
> make invocations.
>
As I indicated in the other email I think Link needs be renamed as
WebResource or similar. Effectively it should become an "Invocation"
with the current existing Invocation taking care of the generic invoke()
and such. A better Link has to be introduced later to represent resource
URIs
Cheers, Sergey
> Bill
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com