Hi,
fair enough, I would have wait for a formal vote before taking the initiative.
We had a proposal/discussion thread, but no formal vote for the acceptance.
I think in term of legal we are good as it's under the Apache license already.
I will do a full review later this week.
Regards
JB
On 10/22/2017 06:16 PM, Christian Schneider wrote:
I have now organized the repo and did the initial push with my current code of
reactive components.
You can find the repo at:
https://github.com/apache/karaf-reactive-components
I would still be happy about a review. I think we should have no licensing
issues as the code was only developed by me and I have an ICLA.
So I can confirm that this is fully apache licensed and written by me.
Please let me know if we need something more formal.
Best
Christian
2017-08-08 14:26 GMT+02:00 Jean-Baptiste Onofré <[email protected]
<mailto:[email protected]>>:
Hi
I will do a new review round tomorrow morning.
Thanks
Regards
JB
On Aug 8, 2017, 13:04, at 13:04, Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
>I now adapted the package names as well as the maven coordinates. All
>files should now also have the apache headers.
>I also made sure the build now works without any running mqtt or kafka
>server.
>
>I would be happy about a quick review of the current status. If there
>are no objections then I will go ahead and ask for a git repository.
>
>Christian
>
>On 03.08.2017 08:02, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>>
>> the proposal is interesting, and I see a first potential use in
>> Decanter for sure.
>>
>> The comment about Camel is fair as it looks very similar at first
>glance.
>>
>> However, the scope is slightly different IMHO.
>>
>> I checked about the legal. The code should be cleanup for donation
>> (ASF headers, package names, ...). About the dependency license, for
>> the reactive-streams, it' OK as it uses Creative Commons Zero into
>the
>> Public Domain. And Reactor is already under Apache license.
>>
>> The DSL is a hot topic. I understand that leveraging Akka or Reactor
>> is easier, but I'm a bit concern that we could be too much "coupled".
>> Maybe our own simple DSL could help. Thoughts ?
>>
>> Thanks anyway !
>> Regards
>> JB
>>
>> On 07/19/2017 01:02 PM, Christian Schneider wrote:
>>>
>>> Scope
>>>
>>> I recently experimented with reactive streams and built a small
>>> component framework on top of this spec.
>>> See https://github.com/cschneider/reactive-components
<https://github.com/cschneider/reactive-components>
>>>
>>> The goal is to have a small API that can encapsulate a protocol and
>>> transport. The code using such a reactive component should not
>>> directly depend on the specifics of the transport or protocol.
>>> Another goal is to have reactive features like back pressure.
>>> Ultimately I am searching for something like Apache Camel Components
>
>>> but with a lot less coupling. In camel the big problem is that
>>> components depend on camel core which unfortunately is much more
>than
>>> a component API. So any camel component is coupled quite tightly to
>>> all of camel core.
>>>
>>>
>>> Proposal
>>>
>>> I propose to donate my code to Apache and establish this as a Apache
>
>>> Karaf sub project. Some people like Jean-Baptiste and Hadrian have
>>> already expressed that they support this and I hope for some more
>>> feedback and help.
>>>
>>> I chose the Karaf project at the moment but am also open to placing
>>> this in another Apache project. Some matching projects would be
>>> Apache Camel, Aries or Felix.
>>>
>>>
>>> Component API
>>>
>>> I was trying to find the simplest API that would allow similar
>>> components to camel in one way mode.
>>>
>>> public interface RComponent {
>>> <T> Publisher<T> from(String destination, Class<T> type);
>>> <T> Subscriber<T> to(String destination, Class<T> type);
>>> }
>>>
>>> A component is a factory for Publishers and Subscribers. From and to
>
>>> have similar meaning as in camel. The component can be given a
>source
>>> / target type to produce / consume. So with the OSGi Converter spec
>>> this would allow to have type safe messaging without coding the
>>> conversion in every component. Each component is exposed as a
>service
>>> which encapsulates most of the configuration. All endpoint specific
>>> configuration can be done using the destination String.
>>>
>>> Publisher and Subscriber are interfaces from the reactive streams
>api
>>> (http://www.reactive-streams.org/ <http://www.reactive-streams.org/>).
So they are well defined and
>have
>>> zero additional dependencies.
>>>
>>> I also considered to use OSGi push streams which is an OSGi spec and
>
>>> would also be an interesting foundation. I decided against that
>>> though as push streams have no API that is separate from the DSL and
>
>>> will probably not be used a lot outside of OSGi.
>>>
>>> See the examples for how to use this in practice.
>>> https://github.com/cschneider/reactive-components
<https://github.com/cschneider/reactive-components>
>>>
>>>
>>> Possible use cases
>>>
>>> Two big use cases are reactive microservices that need messaging as
>>> well as plain camel like integrations.
>>> Another case are the Apache Karaf decanter collectors and appenders.
>
>>> Currently they use a decanter specific API but they could easily be
>>> converted into the more general rcomp api.
>>> We could also create a bridge to camel components to leverage the
>>> many existing camel components using the rcomp API as well as
>>> offering rcomp components to camel.
>>>
>>> Components alone are of course not enough. One big strength of
>Apache
>>> Camel is the DSL. In case of rcomp I propose to not create our own
>>> DSL and instead use existing DSLs that work well in OSGi. Two
>examples:
>>>
>>> Akka and reactive streams
>>>
>https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams
<https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams>
>>>
>>> Reactor and reactive streams
>>>
>https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring
<https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring>
>
>>>
>>>
>>> Another integration is with REST. It is already possible to
>integrate
>>> CXF Rest services with reactive streams using some adapters but we
>>> could have native integration.
>>>
>>>
>>> Risks and Opportunities
>>>
>>> The main risk I see is not gathering a critical mass of components
>to
>>> draw more people.
>>> Another risk is that the RComponent API or the reactor streams have
>>> some unexpected limitations.
>>> The big opportunity I see is that the rcomp API is very simple so
>the
>>> barrier of entry is low.
>>> I also hope that this might become a new foundation for a simpler
>and
>>> more modern Apache Camel.
>>>
>>> So this all depends on getting some support by you all.
>>>
>>> Christian
>>>
>>>
>>
>
>--
>Christian Schneider
>http://www.liquid-reality.de
>
>Open Source Architect
>http://www.talend.com
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
