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.
