[feature request] simplify defining RequestHandler

[yschimke]

Some possible options to make it simpler to use, especially around "kicking the tires" style functionality

• A builder approach like the java where you standard with a concrete RequestHandler that rejects all requests and then add handlers
• base class with concrete methods you can override
• concrete utility classes for things like subscriptions with default behaviour e.g. when not implementing handleRequestChannel

[yschimke]

I think there is an open question for how request handlers should indicate that they don't support some operation e.g. a channel. Is an exception the correct mechanism for C++ here? That could be translated into a error frame for the stream.

Maybe just call onError on the Subscriber you are provided with in the handler? That should work since all relevant code is already hardened with ExecutorMixin. Is it worth trying?

I have a strong bias against exceptions.

[yschimke]

The downside is it seems like a need to return a valid return object still for the channel case. Even if I only want my RequestHandler to support metadataPayload (stupid I know) I need to define these classes.

Also strange if you still need to call onSubscribe because of the contract.

We can make that better with default implementations, e.g. return a FailedSubscriber.

  virtual reactivesocket::Subscriber<reactivesocket::Payload>&
  handleRequestChannel(
      reactivesocket::Payload request,
      reactivesocket::Subscriber<reactivesocket::Payload>& response) {
    auto input = *(new reactivesocket::MemoryMixin<FailedSubscriberBase>());

    response.onSubscribe(input);

    response.onError(unsupportedException());

    return input;
  }

I'm ok either way, mainly calling out that we (any of us) should implement and document this in future.

Oh, we could provide default implementation of RequestHandler::request* that closes the stream/drops FnF message/whatever else. I'm wondering how should we do that, i.e. should we special-case it in automata implementations and throw exceptions or use existing mechanism.

Also strange if you still need to call onSubscribe because of the contract.

Hmm, sounds like we could theoretically make it optional without increasing the # of states of the backing automaton. Will think about it.

[yschimke]

done via extending DefaultHandler