Operating System: All
Platform: All

We will need to implement BindingCodecTree.getSubtreeCodec(SchemaNodeIdentifier), so that we can efficiently lookup RPC input/output as well as notifications. Once we have that, we can properly bind methods to their SchemaContext counterparts without having to go through the codec.

This should result in a BindingDOMRpcProviderServiceAdapter having a

Cache<Class<? extends RpcService>, RpcServiceClassContext> rpcServiceClasses;

populated lazily as services are registered. Furthermore RpcServiceClassContext should have the basic shape of:

final class RpcServiceClassContext implements Immutable {
    final ImmutableMap<SchemaNodeIdentifier, RpcServiceMethodContext> methods;
}

Note the methods map should not be used during invocation, only during decomposition of the RPC implementation – the keys are input to DOMRpcIdentifier and values form the invocation context, which in turn looks like this:

final class RpcServiceMethodContext implements Immutable {
    final QName inputQName; // Note: shared between all MethodContexts in a ClassContext
    final BindingNormalizedNodeCodec inputCodec;
    final BindingNormalizedNodeCodec outputCodec;
    final RpcMethodInvoker methodInvoker;
}

now when an implementation is registered, we look up the RpcServiceClassContext and for each RpcServiceMethodContext we create a DOMRpcImplementation, which has a pointer to the MethodContext and the RpcService object being registered.

During invocation we use the inputCodec/inputQName combo to create the DataObject representation of input and pass that to the methodInvoker. We then return a variation on LazyDOMRpcResultFuture, which actually holds a reference to outputCodec directly, not going through the codec/codecRegistry.

Note that since the DOMRpcImplementations created are not multiplexing but rather each points to a single YANG RPC, we do not consult DOMRpcImplementation.invokeRpc()'s first argument.

The problem with this decomposition, though, is that the resulting object would not be registered atomically – for that we will need an atomic

DOMRpcProviderService.registerRpcImplementations(Map<DOMRpcIdentifier, DOMRpcImplementation>);

method and have that implemented.

I think we can address this cleanly by removing the Adapter, as we won't be needing it.

Actually, we can implement an efficient split by reusing the DOM and Binding infra existing for single-RPC invocations.