On 26/08/11 17:58, Sergey Beryozkin wrote:
> 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.
typos, typos, wanted to say that Invocation can encapsulate gets and
posts and deletes and puts. I don't believe addressing batched posts or
a combination of gets and posts is realistic at the api level - it's a
different spec/technology area. I think users who write code would
consider doing custom batched processors if they wanted to go there
Sergey
> 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