On Aug 29, 2011, at 11:24 AM, Sergey Beryozkin wrote:
>>>>> Yes. I think many specifications try to incorporate a lot of edge cases and end up seriously bloating themselves. This may be one of those scenarios. At the time, it seemed like a good idea that wouldn't affect the API very harshly. Things have changed.
>>>>
>>>> -1
>>>>
>>>> Although in general I support the idea of simplifying the API, I disagree generic invocations is an edge case. Support for generic invocations is needed to make invocations first class; the ability to configure and store invocations in data structures for later retrieval and execution gives developers a greater flexibility on how to modularize (large) applications and it also enables lazy execution of invocations.
>>>>
>>> 1. Do you really believe that most of JAX-RS 2.0 client API users will code invoke() in the end of the chain ? Your -1 seems like a fairly strong preference of invoke() at the end for all the cases.
>>
>> No, that's not what I meant. I'm OK with the use of the method name at the end. However, I also like having the ability to pre-configure an invocation (including its method), store it in a data structure and execute it later in a another module by using invoke()/submit(), i.e. without the other module knowing what type of invocation it's executing.
>>
>> Hope that clarifies my position.
>>
>
> I'd appreciate if you could at least evaluate a proposal referred to at 2. below. That allows for preconfiguring target and initializing Invocation with it and keep in structures and such - if it's what is needed...
>
>>> 2. What is your position re the compromise proposal to do with letting users code get()/etc at the end of the chain without paying the price of typing request() yet still easily being able to create Invocations
I'm in favor of keeping request(), but I could live without it if it comes to that. As I said, I do want to keep the generic interface to execute pre-configured invocations.
-- Santiago