Support for handling of extension frame
RSocket spec supports Extension frames: https://github.com/rsocket/rsocket/blob/master/Protocol.md#frame-ext
Add a way to handle extension frames
This or #582.
@robertroeser if possible to have draft design for frame extension. for example, an interface for Frame handler(ServiceLoader) and payload handler functional interface specification.
public interface RSocketFrameExtensionHandler {
int frameType();
int streamIdType();
FrameFlyweight frameFlyWeight();
PayloadDecoder payloadDecoder();
//functional interface class
Class<?> handler();
}
public class RSocketHandlerImpl extends AbstractRSocket implements FrameExtRSocket {
@Override
public Mono<Payload> savePointAck(Payload payload) {
return Mono.empty();
}
}
@linux-china I will take a look at what could be done
One handy pattern from the Scrooge Thrift compiler, when it doesn't understand elements in a thrift frame, it still allows pass through. So for example a thrift struct gets a new field added, or a new enum value is added which is unknown to the server based on it's deployed thrift IDL. It is still allowed to introspect that element even just pass through when the server is a proxy for example.
Not sure we want that, or it implies a "must understand" discussion.
e.g. https://twitter.github.io/scrooge/GeneratedCodeUsage.html
I guess it would work only in case of proxying on the level of the state machine (frame handler which interprets all the frames)