I don't see how my proposal to extend CompletionStage would break anything,
if it's only used as a return value. It can be easily down-cast to
CompletionStage and used as a normal CompletionStage.
Although I would disagree, I understand and accept that you don't think
this is a better solution.
Thanks,
Ondrej
2017-01-19 15:40 GMT+01:00 Santiago Pericasgeertsen <
santiago.pericasgeertsen_at_oracle.com>:
> Hi Ondrej,
>
> These extension points are not really intended for app developers, their
> main target is framework developers (or in this case JAX-RS implementors).
> Moreover, in my view, to break ties with JDK’s CompletableStage in your
> proposal will likely require more work than you anticipate.
>
> It is very likely that JAX-RS 2.1 implementations will support other
> types beyond CompletableStage right out of the box.
>
> — Santiago
>
> On Jan 17, 2017, at 4:24 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com>
> wrote:
>
> Hi Santiago,
>
> My proposal brings 2 advantages:
> - move the clutter from of the alternative rx() methods from the
> InvocationBuilder one step later, after rx() is called (it is not relevant
> for those using the default invoker based on CompletionStage)
>
> - to reduce the amount of methods to implement, if an app developer wants
> to implement a custom invoker - the current solution requires to implement
> 25 methods in RxInvoker interface, my solution builds on the Rx default
> invoker and requires only to implement 2 methods ( getCallback();
> getUnwrapped();)
>
> I know that for the second point, your vision is that the RxInvoker is
> implemented by a third party library, but even though, having to implement
> 25 methods is very inconvenient IMHO. I don't think that alternatives need
> to implement actual get, post, etc. calls, only how to handle the async
> result. The InvocationCallback approach in AsyncInvoker is enough, but it
> is hard to integrate with reactive API.
>
> I'll try to provide an example in couple of days when I have time.
>
> I appreciate that you consider my suggestions, even if they won't be
> accepted.
>
> Ondrej
>
> 2017-01-17 20:49 GMT+01:00 Santiago Pericasgeertsen <
> santiago.pericasgeertsen_at_oracle.com>:
>
>> Hi Ondrej,
>>
>> I’m not sure if I fully understand your new proposal. In any case, I
>> fail to see why it is better than the currently proposed one. In fact, at
>> first glance, it seems more complicated if I’m honest.
>>
>> An actual example using, say, RxJava may help. Otherwise, I think we
>> should continue improving the current approach.
>>
>> — Santiago
>>
>> On Jan 17, 2017, at 12:14 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com>
>> wrote:
>>
>> In fact, on second thought, it's not true we have to have
>> CompletableFuture in the chain at all. The CompletionStage is an interface,
>> which can implement the ability to convert to use any provider. The
>> provider doesn't have to use the CompletionStage at all, we can go deeper
>> and let it implement a custom InvocationCallback instead.
>>
>> I just wanted to make it simple. But if you want to bypass
>> CompletionStage, imagine this (I slightly modified my original proposal):
>>
>> client.request().rx().get(). // we get the RxCompletionStage here, which extends CompletionStage
>> .unwrap(this::provideInvocationCallbackAndRxFlowable) // accepts a producer function, which returns an InvocationCallback AND Flowable, which will be the result of the unwrap method (the 2 return values wrapped in a new container interface)
>> .subscribe(s -> testResult = s, Throwable::printStackTrace);
>>
>> with these definitions:
>>
>>
>> <UNWRAPPED> UNWRAPPED unwrap(Producer<Unwrapper<RESPONSE_TYPE, UNWRAPPED>> unwrapperProvider);
>>
>> and
>>
>> interface Unwrapper<RESPONSE_TYPE, UNWRAPPED> {
>>
>> InvocationCallback<RESPONSE_TYPE> getCallback();
>>
>> UNWRAPPED getUnwrapped();
>>
>> }
>>
>> The producer passed to unwrap() would just need to implement the
>> callback, which forwards to the new UNWRAPPED instance (e.g. Flowable in
>> RxJava2).
>>
>> The invocation callback can be execute mutiple times, making it possible
>> to send multiple events (unlike using CompletionStage), but I don't think
>> that makes sense in REST client.
>>
>>
>> Do you think this could work? Should I try to elaborate further and
>> provide a working example?
>>
>> Ondrej
>>
>>
>> 2017-01-17 17:20 GMT+01:00 Santiago Pericasgeertsen <
>> santiago.pericasgeertsen_at_oracle.com>:
>>
>>>
>>> On Jan 15, 2017, at 1:37 PM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
>>>
>>> I guess the second quiestion is almost reduced to the first one - do we
>>> really want to have CompletableFuture ALWAYS in the chain? (or to be more
>>> on point - do we want to create JaxRsCompletableFuture and use that as an
>>> "rx extension point"?)
>>>
>>>
>>> This is the biggest issue with this proposal, it’s just delegation to
>>> CompletionStage, always. This is not the same as the RxInvoker proposal, in
>>> which other Rx library can be “natively” integrated.
>>>
>>> This is a showstopper for me, so -1.
>>>
>>> — Santiago
>>>
>>>
>>>
>>>
>>
>>
>>
>
>