aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Utzig <>
Subject Re: Aries RSA - support for long running calls
Date Mon, 25 Jul 2016 07:49:39 GMT
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.

Best regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message