On 6/27/11 11:26 AM, Marek Potociar wrote:
> Here are some observations:
>> 1. ClientFactory is factory of clients
>
> It was not there, was added based on EG request.
>
Yes, we wanted Client to be an interface.
>>
>> 2. Client is a factory of Links but also a factory of Invocations.
>
> True.
>
>>
>> 3. Link **is** effectively a Client even though Links are supposed to be identifiers of resources Clients are supposed
>> to work with.
>
> I did have this design at one time, but then I got a feedback that I am missing the instance to hold expensive
> initialization.
>
The current Link abstraction is very nice because you can configure
things like security for a specific resource that you are going to
invoke on more than once. YOu can also pass Link references around
without also having to worry about passing Client references as well.
>>
>> 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.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com