In Helium Binding APIs there was the provision for reacting to notification subscribers coming in. This was deemed to be an accidental leak and that capability was not brought forward in Lithium+ Binding APIs.

Aluminium removal of controller APIs is showing that there actually is a valid use case for this API, which is notification transformations.

This is used in l2switch, which uses the legacy API to lazily register notification listeners, which also act as notification producers: https://github.com/opendaylight/l2switch/blob/release/oxygen-sr4/packethandler/implementation/src/main/java/org/opendaylight/l2switch/packethandler/decoders/AbstractPacketDecoder.java#L48

This means they act as functions: they take a notification of some input type and produce a notification of some output type. The lazy bit is a clever optimization, as the input notifications are not listened to until there is somebody interested to receive the output.

Luckily we have not lost the underlying DOM SPI mechanics, hence we can still reconstruct the capability.

Design a replacement API, which really needs to work in terms of the transformer being something like:

@FunctionalInterface
public interface NotificationTransformer<I extends Notification, O extends Notification> extends Function<I, List<? extends O>> {

}

and being registered something like: 

<I extends Notification, O extends Notification> Registration registerNotificationTransformer(Class<I> input, Class<O> output, NotificationTransformer<I, O> transformer);

for starters the implementation should react to listeners coming. Downing transformers is currently not needed, but should be doable, provided we can do something about loops (i.e. A-to-B and B-to-A transformers being in existence). Cluster forwarding can make this hard.