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
>>
>>
>>
>>
>
>
>