Hi Tim, please see comments inline.
> I have to ask, why would you not use OSGi Promises for this? Representing > Long running and/or asynchronous tasks is exactly what OSGi Promises were > designed for. They're also much simpler than CompletableFuture (which is a > horrible API to try to use), and tie in to the rest of the OSGi ecosystem > (for example the current Asynchronous Services spec, the proposed Push > Stream spec and the next Log Service updates) > Because I did not think of that. I just updated the implementation to also work with Promise, thanks for the hint! > > There is already an RSA 1.2 update needed in the next OSGi specification > release - I would be happy to work with you to define a remote services > config type for asynchronous remote service support. That way this > behaviour would also be portable between implementations. > > I think that having a standard here is important, because there are > actually a lot of different RSA implementations in the wild, and if they > all do things completely differently then it will be confusing to users and > result in the feature not being used. It will also help to ensure that the > different providers hosted by single projects (Aries RSA and ECF both have > multiple options here) are self-consistent. > > I think having something like this in the standard would be great. Is this approach something that you could see making it into the standard? Another thing that would IMO make a lot of sense to add to the RSA spec is an interface for plugging in new distribution providers. I don't know if you are aware of the service interface Christian created for aries-rsa, but having something like that in the actual spec would enable users to mix and match the transport layers of different RSA implementations. https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/DistributionProvider.java Best regards, Johannes
