DOMRpcService has integrated support for availability listeners, from long time ago. DOMActionService has the equivalent (but delta-driven) capability exposed via an extension.
RPCs and Actions are essentially the same thing, behaving very much the same way, so the two should take the same approach.
There are points to argue both ways:
an implementation bound to an EffectiveModelContext can enumerate the available RPCs and can react to schema changes
a random implementation may not be cognizant of what it actually can route
In DOM world, we assume NormalizedNodes, which need EMC support to translate to/from XML/JSON/CoAP. But that is not be-all and end-all of serialization and it is possible, but not likely, that a provider could marshall NormalizedNodes to and from a remote service which DOES NOT expose a push channel as to what is actually available.
When we take MD-SAL to a distributed system, we assume that information about RPC endpoints is flooded, with DOMRpcImplementation.invocationCost() driving routing selection – potentially crossing multiple relays until the endpoint is reached.
The other argument is that plain DOMActionService does not support any sort of enumeration – which is a hindrance to reflection and being friendly to humans asking "what is it I can do with this system?"
Finally, there is point of DOMNotificationPublishDemandExtension, which essentially is the opposite – informing a client of DOMNotificationPublishService that it should start producing some DOMNotifications if it can. The lifecycle is different, as it pertains to dynamic subscription, but the synchrony is the same.
With all that context, I think we should integrate DOMActionAvailabilityExtension into DOMActionService – thus saying that yes, available operations can be enumerated and can change in time (the problem with DOMSchemaService being a separate issue).
So this task boils down to two things:
eliminating DOMActionAvailabilityExtension and integrating its functionality directly into DOMActionService
reconciling the shape of DOMActionAvailabilityExtension.AvailabilityListener and DOMRpcAvailabilityListener
On that second point, I really think we should go with AvailabilityListener model, where we receive a disjunct delta: this was added, this was removed. This saves users from calculating a delta. The question to be answered is what to do about resyncs – perhaps we need to callbacks:
DOMRpcService has integrated support for availability listeners, from long time ago.
DOMActionService has the equivalent (but delta-driven) capability exposed via an extension.
RPCs and Actions are essentially the same thing, behaving very much the same way, so the two should take the same approach.
There are points to argue both ways:
an implementation bound to an EffectiveModelContext can enumerate the available RPCs and can react to schema changes
a random implementation may not be cognizant of what it actually can route
In DOM world, we assume NormalizedNodes, which need EMC support to translate to/from XML/JSON/CoAP. But that is not be-all and end-all of serialization and it is possible, but not likely, that a provider could marshall NormalizedNodes to and from a remote service which DOES NOT expose a push channel as to what is actually available.
When we take MD-SAL to a distributed system, we assume that information about RPC endpoints is flooded, with DOMRpcImplementation.invocationCost() driving routing selection – potentially crossing multiple relays until the endpoint is reached.
The other argument is that plain DOMActionService does not support any sort of enumeration – which is a hindrance to reflection and being friendly to humans asking "what is it I can do with this system?"
Finally, there is point of DOMNotificationPublishDemandExtension, which essentially is the opposite – informing a client of DOMNotificationPublishService that it should start producing some DOMNotifications if it can. The lifecycle is different, as it pertains to dynamic subscription, but the synchrony is the same.
With all that context, I think we should integrate DOMActionAvailabilityExtension into DOMActionService – thus saying that yes, available operations can be enumerated and can change in time (the problem with DOMSchemaService being a separate issue).
So this task boils down to two things:
eliminating DOMActionAvailabilityExtension and integrating its functionality directly into DOMActionService
reconciling the shape of DOMActionAvailabilityExtension.AvailabilityListener and DOMRpcAvailabilityListener
On that second point, I really think we should go with AvailabilityListener model, where we receive a disjunct delta: this was added, this was removed. This saves users from calculating a delta. The question to be answered is what to do about resyncs – perhaps we need to callbacks:
void onActionsChanged(Set<DOMActionInstance> removed, Set<DOMActionInstance> added);
void onActionsSet(Set<DOMActionInstance> available)
The second is the equivalent of saying "I don't know what is the last delta you have seen, this is the set we start from".