rsocket-cpp
rsocket-cpp copied to clipboard
RSocket API TODOs
Ondrej and I capturing things we're finding to do
- [x] requestResponse with Single<T> type
- [x] fireAndForget with Single<Void> type
- [x] adopt yarpl::flowable::Subscriber/Subscription types in core code
- [x] RSocketRequestHandler -> RSocketResponder (rename to match spec terminology)
- [x] Separate single-threaded and thread-safe API layers
Ondrej and I discussed a possible layout as follows...
Thread-safe layer is:
- RSocketServer, RSocketClient, RSocketRequester, RSocketResponder
Single-threaded layer is:
- RSocketStateMachine (currently ConnectionAutomaton)
- containing DuplexConnection and Responder
- exposing request APIs
Most applications would use the thread-safe layer and higher-levels APIs, but something wanting lower level single-threaded behavior could instantiate an RSocketStateMachine directly with a DuplexConnection and operate on the single thread.
- [ ] Observers/Singles overrides of onComplete/onNext calling super to release?
- [ ] default maximum request(n) over network to something reasonable (128?)
- [x] simplify examples (subscribe overloads with lambdas for example)
- [x] RSocket requestResponse unit tests
- [x] RSocket requestStream unit tests
- [x] RSocket requestChannel unit tests
- [ ] RSocket fireAndForget unit tests
- [ ] consistent naming convention of methods in public APIs (either getter or not getter style)
- [x] collapse ConnectionSetupRequest and SetupParameters
- [x] collapse ConnectionResumeRequest and ResumeParameters
- [x] collapse RSocketConnectionHandler and ConnectionHandler
- [ ] cleanup the public API of Payload (for example the clear() method probably should be public?)
- [ ] finish eliminating or refactoring classes in /src/temporary_home
- [ ] make sure stream state machines dont call subscription::cancel after on{Complete,Error}
- [ ] make sure stream state machines dont call subscriber::on{Complete,Error} after cancel()
- [ ] cleanup Payload API
- [ ] make sure that writing a payload to a stream from the right thread is going to synchronously be written all the way to the duplexconnection
- [ ] fix incostistent naming for Flowables::fromPublisher vs. Observable::create (Single::create)
- [ ] Flowable::fromPublisher provides subscriber to the lambda which is already subscribed to the subscription, Observable and Single require to call onSubscribe in the lambda. That is inconsistent. We should have the same behavior.
Which of these still need to be done? If any perhaps we should split them out into their own tasks now since the sprint is more-or-less complete to get the new APIs adopted?