aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject Re: Aries RSA - support for long running calls
Date Mon, 25 Jul 2016 14:12:04 GMT
Hi Johannes,

More comments inline.

Sent from my iPhone

> On 25 Jul 2016, at 08:49, Johannes Utzig <> wrote:
> 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?

That's exactly what I'm suggesting.

> 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.

This is already part of the specification. The plugin interface is called RemoteServiceAdmin,
and it has been widely adopted. Some projects like ECF and Aries have created lower level
Plug points, but that shouldn't be a requirement for all RSA providers as it forces them to
be bigger and more complex.

> Best regards,
> Johannes

View raw message