Fixes issue #169 #176
Fixes issue #169 #176
Conversation
NiteshKant
commented
Jul 4, 2014
NiteshKant
commented
- Modified HttpClientRequest to take an Observable for content instead of the earlier ContentSource.
- Retained the capability to use an Observable<S> where S is not the type of the HttpClientRequest. This mode requires passing a function that converts S to ByteBuf.
- Removed the RepeatableRequest functionality as it is not required. Re-subscribing to the content observable should replay the source.
- Modified HttpClientRequest to take an Observable for content instead of the earlier ContentSource. - Retained the capability to use an Observable<S> where S != type of the HttpClientRequest. This mode requires passing a function that converts S to ByteBuf. - Removed the RepeatableRequest functionality as it is not required. Re-subscribing to the content observable should replay the source.
|
RxNetty-pull-requests #107 SUCCESS |
|
Looks good to me. The only question I have is whether we can assume re-subscribing the content will replay the source. If the source is a PublishSubject, re-subscribing will only get the elements subsequent to the time of subscription. In that case, we might need to make use of ReplaySubject if we need to repeat the same request. Of course, for majority of use cases the Observable is created using Observable.just() or from(), where re-subscribing will cause replay. We can also document the API to ask caller to provide the Observable which always replays when subscribing, if the request is deemed as "repeatable" by the caller. |
|
The general contract of I think people using rx would relate to this concept. |
