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 <[email protected]>:
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 <[email protected]> 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 <[email protected]> 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
