>
>>> 5. get().params(...).invoke() just reads wrong; the whole idea is to capture the fact clients are doing HTTP centric
>>> programming with get()/etc and here get() is just lost in the noise with faceless invoke() finishing the chain.
>> I guess with fully mutable requests, the method name can get lost any time. Also, when I had a very first proposal where
>> this was at the end, the proposal was viewed as too complex since there were more builder interfaces involved. Also, for
>> me, it is a MUST HAVE that a request is *ALWAYS* fully initialized (i.e. it has a URI and method set).
>>
>
> invoke()/queue() works nicely with the Command Pattern. A generic
> subsystem could gather up Invocation requests and invoke them without
> worrying about what the method is or which Client it was created from.
Why don't let users just use Executors, sockets and such directly ?
The problem is, accommodating this good feature, the ability to queue
invoications, spills into Client API and users don't do HTTP but
invoke/run/execute. API should not be affected IMHO
Sergey
>
> Bill
>