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.
