MicroProfile 2.1 Status & Reactive Streams Operators

[John Clingan]

OK, at the moment we have the following three specifications defined for MicroProfile 2.1:

• Config 1.4
• OpenTracing 1.2
• Reactive Streams Operators 1.0

I'm looking for final confirmation of specs before the release is created. There was some discussion as to whether or not we should include Reactive Streams Operators since its not truly useful until a spec like Reactive Streams comes along to layer on it. However, I like the idea of including it because it is "done" and can generate interest in MicroProfile within a "new community" of developers. So, before the release is created, let's hash this out. Discussion deadline - Tuesday, Sep 11th. Go! :-)

[Emily Jiang]

John,

I think you meant MicroProfile 2.1, right?

My opinion still is:

We should NOT include Reactive Streams Operators 1.0 in MicroProfile 2.1.

It is such a low-level spec. If we include it, the end users cannot easily use it. With this spec release, we will get asked: How to easily use it? "ummm... good questions." or "you need to use this lib and then do 1, 2,3" will not sell well. I think it will not do us any good either, as we have been striving to deliver easy-to-use APIs.

If you want to release MicroProfile Reactive Streams Operators but not include it in MP 2.1, it should be ok. Thinking it again. I think this might be a good option. It shows we are going reactive, but we need a bit more time to get it perfect . If anyone wants to play with it, they can. We can then push to get messaging released in 4Q. Just a couple of months, we can be sure the Reactive Stream Operators is good enough.

my 2cents

Thanks
Emily

On Friday, September 7, 2018 at 10:01:20 PM UTC+1, John Clingan wrote:

OK, at the moment we have the following three specifications defined for MicroProfile 3.1:

[John Clingan]

On Friday, September 7, 2018 at 3:23:29 PM UTC-7, Emily Jiang wrote:

John,

I think you meant MicroProfile 2.1, right?

My opinion still is:

We should NOT include Reactive Streams Operators 1.0 in MicroProfile 2.1.

Fixed. Thanks.

 

It is such a low-level spec. If we include it, the end users cannot easily use it. With this spec release, we will get asked: How to easily use it? "ummm... good questions." or "you need to use this lib and then do 1, 2,3" will not sell well. I think it will not do us any good either, as we have been striving to deliver easy-to-use APIs.

My reply - "This is the first step towards reactive development with MicroProfile. While this spec is not intended for broad use, it does offer a starting point for those interested in Reactive APIs to contribute within MicroProfile"

If you want to release MicroProfile Reactive Streams Operators but not include it in MP 2.1, it should be ok. Thinking it again. I think this might be a good option. It shows we are going reactive, but we need a bit more time to get it perfect . If anyone wants to play with it, they can. We can then push to get messaging released in 4Q. Just a couple of months, we can be sure the Reactive Stream Operators is good enough.

We don't really have a process to do this quite yet outside of general agreement to "make it so" (our process to date :-) ).  In a similar manner, Richard mentioned during the live hangout that we could make new specs candidate releases before adding them to the platform to give time for developers to play with it (implies implementation) or do some deeper review before we make it a core part of the platform. Sigh, I need to work up the google doc on spec process. On my to-do list. I'll try to tackle that this weekend.

[Guillermo González de Agüero]

I was thinking about this exactly. If the spec is truly final, it can be released and announced along MicroProfile 2.1 as a new MicroProfile spec that is not yet part or the platform and so vendors don't *have to* implement it, although they are free to do so.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cfda2b22-bab8-4582-9fe9-49fb1fbf9609%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clement Escoffier]

Hello,

While, like any specification there will be updates, the Reactive Stream operators is already in good shapes. I have demonstrated its usage as part of a Vert.x application and a RestEasy (Jax RS) application. Yes, Today to use this spec you need reactive API to consume and that’s why I used Vert.x and RestEasy that paves the road, among others projects such as Alpaka, RX Java, Reactor, in term of “reactiveness”. It’s a “catch-22” problem - without the spec we won’t have API do consume, requiring third-party libraries. Would be a separate release be enough? I’m not sure. It would look like half-backed while, as said, it’s already in a usable state and only real usage will give us feedback, especially the integration into other MP specs such as the Rest client. 

Waiting for Reactive Messaging to be ready to attach the Reactive Streams Ops to MicroProfile induces a delay and this delay is not yet determined. The messaging spec is far from being ready and there are many points to be discussed before having something ready (Note: Red Hat is working on an implementation as part of the SmallRye umbrella). The target is still end of this year, however it may be postponed. 

BTW, the Reactive Stream Ops spec is not “low-level” - it’s the user API expected to be used when manipulating streams of data. I understand it’s a shift in comparison of traditional Java API but this is the reactive-way. 

Clement

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUZh3wtSfVXnxU6uVo5WOdLKXuf-2fmLus-gSxje%2BnMrSw%40mail.gmail.com.

[Ondro Mihályi]

Hi Clement,

I believe that the reactive API is important, but I also agree with Emily that if it's not integrated with other MP specs, adding it to MP is a little risky.

Ideally, there's some other MP spec that would try to support the latest milestone version of reactive API and to provide feedback how it goes. If there's a reasonable feedback on the reactive spec from within the MP project, I agree to release the spec, soon followed by a release of another MP spec that supports it.

Messaging is one candidate to provide feedback and depend on the reactive streaming API, but maybe we could find a faster way to get feedback. Maybe some existing specs could also support the streaming API? For example REST Client has asynchronous support and could support streaming API out of the box. Similarly, Fault Tolerance is adding async support these days and maybe could support the streaming API.

Ondro

[Viktor Klang]

Hi all,

my 2 cents inline:

On Saturday, September 8, 2018 at 12:23:29 AM UTC+2, Emily Jiang wrote:

John,

I think you meant MicroProfile 2.1, right?

My opinion still is:

We should NOT include Reactive Streams Operators 1.0 in MicroProfile 2.1.

It is such a low-level spec.

I'm not sure I agree, but if you mean "important & foundational" then I agree, as is provides cross-component interoperability, and to me that means that it is important to include as soon as possible/feasible.

 

If we include it, the end users cannot easily use it. 

With this spec release, we will get asked: How to easily use it? "ummm... good questions." or "you need to use this lib and then do 1, 2,3" will not sell well.

According to the README there are 3 implementations of which one is a "Zero Dependency" one: https://github.com/lightbend/microprofile-reactive-streams/tree/master/zerodep

 

I think it will not do us any good either, as we have been striving to deliver easy-to-use APIs. 

 

Is there a problem with the spec, the API, or is this more about how it is packaged?

If you want to release MicroProfile Reactive Streams Operators but not include it in MP 2.1, it should be ok. Thinking it again. I think this might be a good option. It shows we are going reactive, but we need a bit more time to get it perfect . If anyone wants to play with it, they can. We can then push to get messaging released in 4Q. Just a couple of months, we can be sure the Reactive Stream Operators is good enough. 

Worth mentioning is that since JDK9 Reactive Streams is a part of the Java Standard Library in `java.util.concurrent.Flow` and that JDK shipped with only one implementation—SubmissionPublisher.

I think that code which connects other code together has a Catch-22 situation which can only be resolved by actually adding it as early as feasible, to let other components start using it.

So my position on this would be: assuming that the spec is ready, and there are several possible implementations, what would be the reason for not including Reactive Streams Operators in MP2.1?

[Ken Finnigan]

I'm +1000 to including Reactive Streams Operators in MP 2.1 for the following reasons:

• It shows MicroProfile is heading down the reactive path and not waiting for this to happen in other places
• It's a building block for other specs to be able to use it
• It's had extensive discussion, iteration and has multiple implementations already compliant with it
• It's usable by developers when wanting to utilize reactive programming

I'd like to point out some concerns with reasoning as to why not to include it:

• Undue requirement for it to be a "perfect" specification, which was not expected of any other spec to date
• Need for it to be used by other specs first. I don't see there being any difference between Reactive Streams Operators and Config in the early days. They're both usable directly and they both provide a foundation for other specifications to build on, but we didn't delay including Config in an MP release because no other spec used it yet
• In addition, requiring it to be utilized by another spec first unnecessarily complicates any future release process and timing. If we wait for Reactive Messaging to be ready to include Streams Operators, what happens if it's not ready for MP 2.2? We keep delaying inclusion of Streams Operators? Doesn't that defeat the original purpose of being fast moving and not afraid to fail? Aligning inclusion of sub specs so heavily also complicates releasing them when they are, requiring Reactive Messaging to wait until Streams Operators is released before doing it's own releases.
• Overall I have the feeling that additional hurdles and requirements are being required of Reactive Streams Operators than any other sub spec to date

Ken

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cf914cd9-f44f-4d04-919b-44d313f89005%40googlegroups.com.

[John Clingan]

Here is where I think we are:

* john C - include

* clement - neutral?

* Ken - include

* Viktor - include

* Guillermo - Release outside of MP 2.1

* Ondro - exclude

* Emily - exclude (or release outside)

* Richard - RC release?

[Guillermo González de Agüero]

Hi,

My opinion would actually be neutral, although I think releasing outside is a compromise solution. But keep in mind I'm not a commiter ;)

Regards,

Guillermo González de Agüero

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d4cea026-a52d-471e-8043-9a75b199c7ba%40googlegroups.com.

[Kevin Sutter]

Since when does Ken get 1000 votes?  ;-)

I can see both sides of this discussion.  Ken is correct that we haven't had a more formal process in the past, so why start now?  Although true, we have been discussing a more formal process in our bi-weekly hangouts.  And, one of the ideas that has garnered some attention for new specifications is to have a "proof of concept" release prior to being released in the MicroProfile platform.  I really like that idea.  I think the Operators spec should go forward with their 1.0 release, but let's hold off on including it in a MicroProfile 2.1 platform release until it's gotten some use.  We could put it on the preliminary list for MicroProfile 2.2.

BTW, I also agree with Ken that having a spec used by other MP specs is not a requirement.  Although it would be nice and probably desired, this has never been a requirement nor has it been discussed.  We have discussed that we shouldn't reinvent the wheel.  For example, don't invent another way to inject configuration when we already have MP Config available.  So, although it may be nice to have another MP platform spec utilize the Reactive Operators spec, it's not a requirement.

-- Kevin

On Monday, September 10, 2018 at 11:37:50 AM UTC-5, Guillermo González de Agüero wrote:

Hi,

My opinion would actually be neutral, although I think releasing outside is a compromise solution. But keep in mind I'm not a commiter ;)

Regards,

Guillermo González de Agüero

El lun., 10 sept. 2018 a las 18:20, John Clingan (<jcli...@redhat.com>) escribió:

Here is where I think we are:

* john C - include

* clement - neutral?

* Ken - include

* Viktor - include

* Guillermo - Release outside of MP 2.1

* Ondro - exclude

* Emily - exclude (or release outside)

* Richard - RC release?

On Friday, September 7, 2018 at 2:01:20 PM UTC-7, John Clingan wrote:

OK, at the moment we have the following three specifications defined for MicroProfile 2.1:

• Config 1.4
• OpenTracing 1.2
• Reactive Streams Operators 1.0

I'm looking for final confirmation of specs before the release is created. There was some discussion as to whether or not we should include Reactive Streams Operators since its not truly useful until a spec like Reactive Streams comes along to layer on it. However, I like the idea of including it because it is "done" and can generate interest in MicroProfile within a "new community" of developers. So, before the release is created, let's hash this out. Discussion deadline - Tuesday, Sep 11th. Go! :-)

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Ken Finnigan]

Don't I always?! Kidding, just expressing my vigorous agreement in having it included in MP 2.1

I'm certainly not saying that we shouldn't have any process, and that we shouldn't be introducing one now.

What concerns me is that we're using Reactive Streams Operators as a guinea pig through an ill defined process that we're developing as we go. If we held off including the spec into MP 2.1, what's required for it to make MP 2.2? I don't believe the inclusion strategy for that is sufficiently defined to know for sure at what point it would be included.

There is still wide disagreement whether a sub spec can be part of MP without any other sub spec using it. Without resolving that issue, there's no clear path to including Reactive Streams Operators in MP until such time as Reactive Messaging is ready.

I'm all for defining a process as to what's required for a sub spec to be releasable and as a follow on, what's required for it to be included in an MP release. However, I don't believe we should hold up Reactive Streams Operators inclusion until we define the entirety of that process.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d4cea026-a52d-471e-8043-9a75b199c7ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/29edafe9-621c-4144-8a3c-b7fa186eb67a%40googlegroups.com.

[John Clingan]

I wonder if this is all a moot point. James is the spec lead and he is out on PTO. I think that it is important to get his take on this thread. 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d4cea026-a52d-471e-8043-9a75b199c7ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Mark Little]

I agree with Kevin. I also understand the concern about "why now and
why reactive?" but honestly we have to start somewhere putting a more
defined process in place. If not reactive then it'll be some other
spec that gets to be the first through that process.

Mark.

> https://groups.google.com/d/msgid/microprofile/CAKeeVe4e510PxvzbpjKhb24xoBRA0-T_usbSjeCMF165tnBj6w%40mail.gmail.com.

[Pavol Loffay]

Hi Jonh,

I am confirming OpenTracing spec to be included in the release. The RC is out and the final release is planned on Friday.

Regards

[James Roper]

Someone said my name?

For the status of the spec itself, I see no reason why we can't start the RC process now and have a 1.0 out in time for MicroProfile 2.1. We've put a lot of effort into the spec itself, the documentation, and the TCK. Conceptually, nothing is new in the spec, it takes (at least) three existing APIs that do the same thing, and creates a standard that takes a heavy amount of influence from an existing Java standard (the JDK8 streams API) for many of the naming and other conventions. We've been very conservative over what gets included in the spec, so I think we're in a good place for 1.0.

One problem with delaying the inclusion in MicroProfile is it does leave the spec in a bit of limbo. It's raring to go and be used now, but what's next? If it's included in MicroProfile, then we're likely to get a lot more usage of it, allowing the spec to continue with the momentum it currently has in addressing any concerns that come up. Whereas if it's not included in MicroProfile, then it will kind of feel a bit weird iterating on it, since on what basis will it move forward? So I'm concerned that not including it now will unnecessarily hold it back.

On the spec inclusion process, I think it would be great if this could be the first thing that follows that process - assuming we can get that process finalised quickly enough for this spec to go through it. John has already proposed a rough process, what if we use that here and see how it goes?

Anyway, back to PTO.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/faf6d621-8c3f-4db7-a25c-db9a4cfdb009%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

[Emily Jiang]

It is not about its being complete but it is about the usage. I always view this operator being the foundation for Reactive Messaging in order for Reactive Message to work with JDK8. I am not aware of discussion for it to be independent.

Back to the start, we never discuss the spec of reactive stream operator being an independent spec. We only approved Reactive Streams Messaging. I cannot seem to find the proposal on the creation of Reactive Streams Operators. Can someone paste a link here? If nothing was discussed in the google group, we need to fill in the gap on the proposal, the use case and we need to find out why and how a repo was created without being discussed...

Emily

[John Clingan]

Thanks Pavol!

[John Clingan]

James, huge thanks for piping in!

So, I think we are getting to a consensus that we can release the specification, and the best means of getting there is as a standalone specification. It is not required that MicroProfile implementations implement the spec to claim "MicroProfile 2.1 compatible" status. It can, however, be optionally implemented and included in implementations as long as it passes the TCK. I don't think we'll get to a formal process definition before MicroProfile 2.1. We are literally out of time. We pretty much need final spec status for all MP 2.1 specs by the end of the week to make CodeOne/EclipseCon Europe/Reactive Summit.

Before the end of the week I'll create a google doc that outlines the process options that we have discussed and we can collaborate on it before Reactive Messaging (or other spec) nears a 1.0 status. This also ties into the definition of a "platform"-level spec, and I'll initiate that discussion in the same document for now.

Good enough for everyone?

On Tuesday, September 11, 2018 at 12:25:20 AM UTC-7, James Roper wrote:

Someone said my name?

For the status of the spec itself, I see no reason why we can't start the RC process now and have a 1.0 out in time for MicroProfile 2.1. We've put a lot of effort into the spec itself, the documentation, and the TCK. Conceptually, nothing is new in the spec, it takes (at least) three existing APIs that do the same thing, and creates a standard that takes a heavy amount of influence from an existing Java standard (the JDK8 streams API) for many of the naming and other conventions. We've been very conservative over what gets included in the spec, so I think we're in a good place for 1.0.

One problem with delaying the inclusion in MicroProfile is it does leave the spec in a bit of limbo. It's raring to go and be used now, but what's next? If it's included in MicroProfile, then we're likely to get a lot more usage of it, allowing the spec to continue with the momentum it currently has in addressing any concerns that come up. Whereas if it's not included in MicroProfile, then it will kind of feel a bit weird iterating on it, since on what basis will it move forward? So I'm concerned that not including it now will unnecessarily hold it back.

On the spec inclusion process, I think it would be great if this could be the first thing that follows that process - assuming we can get that process finalised quickly enough for this spec to go through it. John has already proposed a rough process, what if we use that here and see how it goes?

Anyway, back to PTO.

On Tue, 11 Sep 2018 at 16:57, Pavol Loffay <plo...@redhat.com> wrote:

Hi Jonh,

I am confirming OpenTracing spec to be included in the release. The RC is out and the final release is planned on Friday.

Regards

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/faf6d621-8c3f-4db7-a25c-db9a4cfdb009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ondro Mihályi]

My status about releasing reactive operators isn't negative. I'm rather neutral to including it in MP, even in favor of on certain conditions.

I agree with Emily that the need for it came from the messaging spec and we never discussed it alone or how it would fit other specs. In comparison, we had discussed the need for config and we concluded it makes a lot of sense to have it in MP.

I encourage to start a discussion about how reactive operators fit into MP and could be used by other specs.I think we can have a vision for it before MP 2.1 is released and then I'd like to include it. It doesn't need to be integrated into other specs but at least needs to have a vision of how to integrate it later. 

So in short, I'm strongly in favor to discuss the future of reactive operators in MP and how it fits in, finish the discussion soon and if we conclude it's useful (I believe so) then include it in MP 2.1 with a roadmap to integrate it better in future MP releases.

--Ondro

Dňa ut 11. 9. 2018, 11:10 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/HS5upySEQCQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c3077b3b-c3c5-4baa-bfab-2a0f625ec119%40googlegroups.com.

[John Clingan]

Repo:

https://github.com/eclipse/microprofile-reactive-streams

It looks like you attended the Aug 14th meeting where these were split into two repos. However, I'm not sure if that meeting implied separate specs.

https://docs.google.com/document/d/1UKBBNFn-CeMih3lNUGvpShcL2aTpnvmJs9LQ8qT9OI0/edit#

Also, we have been talking about it as two specs for quite a while now (even in the Live Hangout).

[Emily Jiang]

I was on holiday prior to that week for 2 weeks. When I attend the call on 14th Aug, the repo was split already. I meant to catch up to find out how and why the repo was split. After a quick search on this forum, I could not find any discussion regarding this.

The consequence of the repo split leads to a new spec release without use cases/usages defined or agreed. Hence it leads to the current different opinions. I suggest in the future any new repo creation should be discussed in the forum as we have done in the past, including repo split, which essentially is the same as new repo creation.

Thanks

Emily

[John Clingan]

Emily, we can make repo creation a part of a formal process when we nail that down. However, based on the feedback so far and the recommendation of the spec lead, we are going to continue moving forward with the Streams Operator as a standalone spec.

Thanks for the feedback!

[Ondro Mihályi]

[A.d. Reactive streams operators]

Hi Emily and others,

I found this discussion that started before operators were split from the messaging spec: https://groups.google.com/d/msg/microprofile/oH6sYZPPMAg/6LnlEazQCgAJ

There was no resolute conclusion, but vast majority agreed to split the operators spec from messaging, so we can't say there was no discussion about relevance of such spec. There was a discussion, and clearly there was wide support for it, so it's OK that we created a separate repository and pushed this spec separately from the messaging spec.

Another thing we agreed on is to first release a milestone before releasing a 1.0 version. We did it.  The intention was that other specs will start working on integrating the milestone version of operators. MP REST client was mentioned as a candidate to do so. There's no version of MP REST client planned for MP 2.1, so no spec would be using operators in MP 2.1. Other candidates are Fault Tolerance, messaging and concurrency, but none of them targets MP 2.1 either. Therefore, I'm afraid that we've gathered no relevant feedback on the milestone version to proceed with the 1.0 version.

As I said earlier, I'm not going to veto inclusion of the operators spec in MP 2.1, although I have the following reasons to wait for a while:

• we released a milestone version but we should gather some feedback from the community or other MP specs before we release a 1.0 version
• there are already implementations of the milestone version, which can be used along MP APIs just by including them as dependencies
• although the spec is based on standard Java 8 Stream API and on 2-3 popular reactive libraries, all these vary a lot in naming conventiens and we may need some space for revisitinng names and semantics of some operator methods. This is impossible without more complex proof of concepts or even realworld usage of the API to gather enough feedback to conserve the API for 1.0 without risking disruptive changes in later versions

So I suggest to wait with releasing operators 1.0 until there's at least some feedback on the milestone version from the community or MP specs. To help with trying out the API, we can create guides or example projects that use an existing implementation of the milestone version of operators API (e.g. James's no-dependency one). We can use it in our conference app or samples repo. We can also present the API at conferences as an alternative to Rx libraries like RxJava. I'll definitely do it in my "Reactive with MicroProfile" talk at Code One and Devoxx.

--Ondro

st 12. 9. 2018 o 0:33 John Clingan <jcli...@redhat.com> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/HS5upySEQCQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6e47ca78-4a24-446d-86cd-8a489d75d536%40googlegroups.com.

[Gosling Von]

Hi,

I've been following the microprofile for a bit time, especially about micro-profile reactive streams/messaging. I also read the discussion carefully, how and when reactive streams are involved and released in MicroProfile 2.1. I wonder could we release the reactive streams/messaging out of the box, Maybe some existing specs could also support the streaming API, such as JMS ?

Do we have a plan to pick up the release of the JMS 2.1 or 3.x? I am not sure whether our microprofile has some relationship with JMS spec :-)

Forget to introduce myself, I am Apache RocketMQ Co-creator and OpenMessgaing spec founder, I am very glad to seek the cooperate with EE community and hope to work together with folks :-)

Best Regards,

Von Gosling

在 2018年9月8日星期六 UTC+8上午5:01:20，John Clingan写道：

[Ondro Mihályi]

Hi, Von Gosling,

Thanks for joining the discussion. I'm glad you expressed your opinion on the operators API. Do you have more concrete feedback about the API? Anything that could be improved, feels strange or even unusable? Or do you think that the API is all fine and ready to be used in real world projects?

If you have any feedback, please post in this thread that I've created to gather feedback on the operators spec: https://groups.google.com/d/topic/microprofile/8wNpjbrCDII/discussion

If you tried the API in the milestone version already, please give some examples of your code where you used the API and maybe also comparision to other APIs (like RxJava) so that we see that the API is really usable and makes sense to developers. So far I'm unaware of any feedback on the API therefore I personally don't feel good about releasing a final version and inclluding it in MicroProfile, although I definitely see the usecase for it and I would really love to have it in MicroProfile.

Cheers,

Ondro

[John Clingan]

Emily and team, can I get a +1 or -1 on Config 1.4 in 2.1?

On Friday, September 7, 2018 at 2:01:20 PM UTC-7, John Clingan wrote:

[Emily Jiang]

John,

Config 1.4 won't be in position to be released next week. I am afraid we need a bit more time and it won't be able to make to MP 2.1.

Thanks

Emily

[James Roper]

I just want to address the topic of splitting the MicroProfile reactive repositories. While from a very early stage, streams and messaging were considered two distinct specs, there were no plans to split the repository, until we came to try and release a milestone of the MicroProfile Reactive Streams Operators spec - something that was agreed that should be done in the MicroProfile Community Hangout. At that point, we found that the MicroProfile release process (ie, the CI build that does the release) assumed one releasable unit per repository, and indeed, the Maven release plugin is heavily built around this assumption too. We would have had to majorly modify the release build to be able to just release MicroProfile Reactive Streams Operators, and indeed be able to have two different 1.0 releases (one for streams, one for messaging) from the same repository. Furthermore, there were a number of other process/technical issues with having them in one repository - we had to manually separate issues for one or the other using GitHub labels, it wasn't clear how we would handle making messaging depend on a stable version of streams while streams was in the same repository as it, etc. So, we decided in the reactive hangout that it would make everything far easier if we simply split the repos. My view of this is it was done purely due to technical limitations of trying to manage two different release lifecycles in the one repository, and in no way changed the status of the streams operators spec as to it being a standalone spec or not.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6e47ca78-4a24-446d-86cd-8a489d75d536%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

Thank you James for the explanation! I tried to join the dots and lines. I brought this up so that in the future we should properly discuss each individual repo creation so that its purpose is well documented and searchable in the mailing list.

Emily

[John Clingan]

MicroProfile 2.1 release created with OpenTracing 1.2

[Pavol Loffay]

Thanks John!