Yes, can imagine it working for GETs. API is also generous enough to
bundle both GETS and POSTs and know one knows what it means at the
application levels. Sorry, I should say I have no clue what it does.
And I also recall you saying we are not creating this API for browsers.
Yes, this may work - but the cost of allowing this possibility is that
most people who want to do plain get will have to type
client.target().request().get().
Why ?
It really 'hurts' seeing this being reintroduced.
Sergey
On 26/08/11 17:50, Marek Potociar wrote:
>
>
> On 08/26/2011 06:38 PM, Sergey Beryozkin wrote:
>> This is a problem - API is centering around an entity which has been introduced for 20% cases and for which we have no
>> particular good example.
>
> I wonder what makes you think so?
>
>>
>> As I said, I don't see it working in practice, having a batched set of sync Invocations, one is GET, other is POST, can
>> you believe it can work ?
>
> I honestly don't have any real-life experience with this usecase in REST. But I believe it can work... Why not? In fact
> I think that's what most browsers do today. They limit the threads per single domain URL (to 2 threads I guess) and then
> when you fetch a page with multiple links to e.g. pictures and article summaries, only the 2 threads are used to fetch
> the data[*].
>
> So, to implement such browser one could use our Invocation API and a worker queue backed by two worker threads. The
> browser would keep adding the new GET invocations to the queue and the worker threads would be invoking them and putting
> the result into the response queue, from which the browser would take and process the responses.[#]
>
>
> [*] You may probably know that one of the optimizations for fast page loading is to distribute the content across
> mutliple servers to workaround the thread limitation imposed by browsers.
>
> [#] Of course, that's not the only way how to implement such browser with our API.
>
>> Thanks, Sergey
>>
>> On 26/08/11 17:34, Marek Potociar wrote:
>>>
>>>
>>> On 08/26/2011 06:22 PM, Sergey Beryozkin wrote:
>>>> On 26/08/11 17:19, Marek Potociar wrote:
>>>>>
>>>>>
>>>>> On 08/26/2011 06:03 PM, Sergey Beryozkin wrote:
>>>>>> In the previous revision Invocation was a 'dead' redundant entity only waiting to be dropped. It's back...
>>>>>
>>>>> As author, I disagree. Invocation is the encapsulation of command pattern concept. It would not be dropped.
>>>>
>>>> As I said in the other email, I'm fine with it staying, as long as we can come up with a more or less realistic example
>>>> showing that command pattern in action, can you please think of one ? I'll +1 if yes
>>>
>>> Typically you would use command pattern whenever you need to execute something in batches. E.g. you are on a network
>>> that experiences intermittent outages so in case of such outage you would queue the (failed) requests and then when the
>>> network is up again, you would execute them using a generic invoke() API.
>>>
>>> Another example would be if you decided to implement a client used by a SEDA[1] stage.
>>>
>>> FWIW, it was originally Bill's requirement to support command pattern, so he may have a concrete real-life example.
>>>
>>> Marek
>>>
>>> [1] http://en.wikipedia.org/wiki/Staged_event-driven_architecture
>>>
>>>>
>>>> thanks, Sergey
>>>>
>>>>
>>>>
>>>>>
>>>>> Marek
>>>>
>>>>
>>
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com