>>>> .rx(CompletionStage.class)
>>>>
>>>> will work with whatever library the users will choose, from Jersey,
>>>> some 3rd party library, etc
>>>
>>> Mine issue with this is that you usually dont want to do
>>> rx(CompletionStage.class). You most likely want
>>> rx(CompletionStage<List<String>>.class), which is not valid Java
>>> syntax. And I must admit I don't like GenericType and I'll be always
>>> trying to find an alternative which won't force that.
>>
>> this is most likely not correct, since rx(Class<T>) doesn't return T
>> but RxInvoker<T> and then that shouldn't be an issue. (since
>> RxInvoker does have get(Class<R>) and it would be defined to return
>> T<R> I guess.
>>
>> Anyway, there is one issue. In mine proposal, rx(..) returns T ?
>> extends RxInvoker, which allows invoker specific methods. Not saying
>> it is a big deal and I don't really think that it will be widely
>> used, but it is a difference.
>
> Interesting, thanks for reminding about it. I'm not sure at the
> moment, from one point of view, that can lead users to writing a less
> portable Rx code, then from the other point of view, given how diverse
> Rx impls can be, it can be hard to restrain all of them by RxInvoker
> alone...That said RxInvoker looks very complete to me as far as Rx
> with HTTP is concerned....
>
not portable when you think about rx(Flowable.class), portable when you
will do rx(FlowableProvider.class), since you can use same
FlowableProvider implementation everywhere.