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