| Re: [ee4j-community] Approach to Reactive in Jakarta EE |
Hi Greg,Perhaps then we could create a ReactiveGuidelines.md in this repo:I could start with making a pull request with a basic skeleton, and then we can collaborate from there?Cheers,JamesOn 20 March 2018 at 15:23, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:James,my preference is that it stays in an eclipse repo..... We are struggling already with our efforts to stay in touch (let alone contribute to) both the EE4J and reactive efforts, so the creation of yet another repository to monitor is just going to increase the barrier for participation (at least for the jetty project).However, I do agree with the approach of using the github tools to collaborate on a README to scope out ideas etc.cheersOn 20 March 2018 at 11:42, James Roper <james@xxxxxxxxxxxxx> wrote:Hi Clement,My mail client decided that your email was a new thread, so I've copied your email below to include it in this thread.I'm ready to make a start on this immediately. At some point in future, I'm guessing there would be a clear way for this to get going, it would come under the umbrella of some committee, a place for the effort to live might be decided, etc, but we're not there yet obviously, committees aren't appointed/elected yet. I propose that we don't let that hinder us, and instead we create a GitHub repo (doesn't have to be in the Eclipse foundation), and work on the guidelines in a README there. We can use GitHub as a place to discuss the minutiae, and use this mailing list/email thread to discuss broader issues, with regular updates posted here to keep the community informed. At some point in future, when the right structures are in place, the guidelines can be officially adopted (probably with further changes after review) by the Jakarta EE working group (or whichever committee is relevant).Does anyone have any objections to that approach?Regards,James
On 19 March 2018 at 00:57, clement escoffier <clement.escoffier@gmail.com > wrote:ClementJames, if you are still thinking about writing these guidelines, you can count on my help.I think that writing some kind of guidelines answering the questions listed by James would be greatly beneficial. In a first version, it could focus on the API (Reactive Streams, CompletionStage...). Topics such as execution model, the relation with CDI can also be covered, maybe in a second step.(I tried to reply to an existing thread that happened before I subscribed to this list, hopefully, it won't mess up everything, especially archives)Hello,On 9 March 2018 at 11:46, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:Jetty is interested as well. Simone Bordet has implemented a few different approaches over the last couple of years on top of Jetty and it would be nice to see a 'good' standard emerge.On Mar 8, 2018 6:17 PM, "Ryan Cuprak" <rcuprak@xxxxxxxxx> wrote:I vote for standardizing reactive programming in Jakarta EE.I have been a fan of Vert.x and would like to see something like that in the platform. It would definitely make justifying its use at work easier if it was part of Java EE (reduces approvals needed).-RyanOn Mar 8, 2018, at 6:08 AM, James Roper <james@xxxxxxxxxxxxx> wrote:Hi all,There are a number of different efforts in different Jakarta EE specs to provide support for reactive features. As many of you may know, I myself have been talking to and investigating a number of different places where Reactive Streams could be useful in Jakarta EE, but these efforts aren't limited to my work - JAX RS 2.1 introduces reactive features in the client, JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0 introduced support for asynchronous sending of responses while Servlet 3.1 introduced asynchronous streaming IO. I've also talked to some spec implementers, such as CDI, who are interested in reactive features but aren't sure where to start.While it's great that this innovation is happening, there is a risk that all these efforts, being done in isolation, will produce a platform that doesn't integrate well with itself, and feels disjointed. For example, if messaging uses an asynchronous streaming API that is incompatible with the streaming offered by the WebSocket spec, then how are people meant to use these two APIs together? If the streaming API for response bodies offered by the JAX RS client is incompatible with the streaming API for response bodies offered by the Servlet spec, how are people meant to use these two APIs together?So I'd like to propose that we start an intentional effort of formalising an approach to reactive in Jakarta EE. What I think we should have answered is questions like:* When should an API use CompletionStage?* When should an API use Reactive Streams?* How should Reactive Streams based APIs be offered?* When should an API introduce its own mechanism/API for handling asynchronous data flows?* How should CDI context be addressed when much of the business logic of an application is moved to callbacks executed by unmanaged threads?I don't know what such an effort would look like in practice - the product might be a wiki page, or perhaps a document with code samples on GitHub. Maybe a dedicated mailing list is needed, or perhaps discussion can be had on another mailing list.Does this resonate with anyone? It's perhaps not on front of everyones minds right now, but it's something that needs to be addressed before mass adoption of reactive features in Jakarta EE happens, and as there are efforts currently in place, the sooner its addressed, the better.Regards,James_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community