aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Utzig <jutzig....@gmail.com>
Subject Re: Aries RSA - support for long running calls
Date Tue, 26 Jul 2016 12:27:10 GMT
Makes sense. However, that means that I probably won't be able to create a
pull request since it wouldn't be able to support CompletableFuture and the
internal implementation heavily relies on CompletableFuture unfortunately...
Any idea what timeframe the next major version has?

2016-07-26 13:37 GMT+02:00 Christian Schneider <chris@die-schneider.net>:

> We should keep the 1.x version on Java 7. For the next major version I can
> imagine to switch to Java 8 but we should
> discuss that as a separate discussion thread so all of the Aries community
> is aware of it.
>
> Christian
>
>
> On 26.07.2016 13:04, Johannes Utzig wrote:
>
>> Hi Tim,
>>
>> I understand your reasoning, thanks for the clearification.
>> Also no problem about the name, no offense taken :-)
>>
>> @Christian
>> Would the switch to target java 1.8 be OK for aries-rsa?
>>
>> Also, while we are at it, I am currently working on another feature that
>> might be interesting for aries. I'd like to support Input/OutputStreams as
>> parameters and return values. A prototype is done, but it still needs some
>> more work.
>> I'd like to contribute that as well if you want it.
>>
>> Best regards,
>> Johannes
>>
>>
>> 2016-07-25 19:08 GMT+02:00 Timothy Ward <timothyjward@hotmail.com>:
>>
>> Apologies - this was meant to be directed at Johnnes. Juggling email on a
>>> phone when you're on a canal boat in Wales can be challenging!
>>>
>>> Tim
>>>
>>> Sent from my iPhone
>>>
>>> On 25 Jul 2016, at 16:35, Timothy Ward <timothyjward@hotmail.com> wrote:
>>>>
>>>> Hi Erwin,
>>>>
>>>> I do appreciate your point of view, but the purpose of a good
>>>>
>>> specification should really be to specify the bare minimum necessary to
>>> solve the client's problem(s)
>>>
>>>> In the case of RSA the problem being solved is "how do I hook discovery
>>>>
>>> layer A into distribution provider B, and manage which services are
>>> imported/exported?". As written the spec allows you to take pieces of
>>> ECF,
>>> Amdatu and Aries RSA and use them all together, which is really valuable.
>>>
>>>> Pluggable transport layers are a different issue, and really only affect
>>>>
>>> people writing RSA implementations, not people using remote services. As
>>> a
>>> result there has to be a really compelling reason to specify that. In
>>> this
>>> case Open Source is doing a good job of providing plugability, and the
>>> fact
>>> that the specification does not require you to support transport plugins
>>> means that you can write smaller distribution provider implementations
>>> for
>>> embedded devices.
>>>
>>>> This ethos is one reason why I think it *is* important to specify the
>>>>
>>> Async behaviour. As someone using remote services it is important that I
>>> know what return types are supported, and how I can recognise RSA
>>> implementations that support Async behaviours.
>>>
>>>> I hope this helps,
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 25 Jul 2016, at 15:38, Johannes Utzig <jutzig.dev@gmail.com> wrote:
>>>>>
>>>>> Hi Tim,
>>>>>
>>>>> please see answer below...
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>> I can accept that answer, but do not fully agree with it. Of course I
>>>>>
>>>> know
>>>
>>>> RemoteServiceAdmin, but most implementations I have seen split the
>>>>> responsibilities into a RemoteServiceAdmin and a pluggable transport
>>>>>
>>>> layer.
>>>
>>>> The different transport layers can be agnostic of the RSA
>>>>>
>>>> implementation so
>>>
>>>> all the aries-rsa transports could easily work in ECF as well, the only
>>>>> reason why that doesn't work is the lack of a standard interface to
>>>>>
>>>> make a
>>>
>>>> transport known to the RSA.
>>>>> When I started working on the 'fastbin' transport of aries-rsa I've
>>>>> also
>>>>> been in contact with Scott Lewis from ECF, and with his help made the
>>>>>
>>>> same
>>>
>>>> transport available in ECF. 99% of the code can be shared, but the entry
>>>>> points need to be rewritten to work with either ECF, or aries-rsa.
>>>>> Having an interface like this in the spec would allow the user to e.g.
>>>>>
>>>> use
>>>
>>>> the RSA of ECF, the topology manager from aries-rsa and the transport
>>>>>
>>>> layer
>>>
>>>> of CXF.
>>>>>
>>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

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