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