Hi Markus,
> * Is that list to be understood as complete, or is there room for additions?
There's always room for additions, but we need to start somewhere.
> This question targets on the open issues in JIRA
JIRAs are, of course, also in scope even though not explicitly listed.
> * The list names SSE but not WebSockets. Is this to be understood as really
> SSE only, hence definitively no WebSocket support?
There's another JSR for WS.
> If that is true, then it
> might at least good to add an example to the specification how to use
> WebSockets with JAX-RS and describe why there is no need for explicit
> WebSocket support due to that.
I don't know if this belongs in our spec, but maybe a best practices document or something like that. Are you volunteering? ;-)
>
> * Why is it JSR 370's responsibility to evaluate MVC requirements when there
> is a separate MVC JSR? What is expected from the JSR 370 EG which cannot be
> done by the MVC EG?
_If_ MVC decides to build on top of JAX-RS (TBD), then we _may_ need to evaluate requirements coming from them.
-- Santiago
> -----Original Message-----
> From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
>
> Sent: Mittwoch, 10. Dezember 2014 20:03
> To: jsr370-experts_at_jax-rs-spec.java.net
> Cc: Marek Potociar
> Subject: Welcome to the JAX-RS 2.1 EG
>
> Hello Experts,
>
> Welcome to the JAX-RS 2.1 (JSR 370) expert group!
>
> This is the official mailing list for the JSR. Note that the old mailing
> list for JAX-RS 2.0 (JSR 339) is still available for 2.0 matters.
>
> Before we start any discussions, I would like everyone to take a couple of
> minutes and read the JSR description one more time to make sure we are all
> on the same page ;)
>
> ===
> 2.1 Please describe the proposed Specification:
>
> Server-Sent Events (SSE) is a new technology defined as part of the HTML5
> set of recommendations for a client (e.g., a browser) to automatically get
> updates from a server via HTTP. It is commonly employed for one-way
> streaming data transmissions in which a server updates a client periodically
> or every time an event takes place.
>
> JAX-RS 2.0 introduced the notion of asynchronous processing for both the
> client and the server APIs. However, asynchronous processing alone cannot
> deliver on all the promises of a modern architecture without the help of
> non-blocking I/O. If only blocking I/O is available, asynchronous processing
> simply pushes the problem from one thread to the next --this is akin to
> borrowing from a person to pay another, the problem is not really solved,
> only deferred. Thus, support for non-blocking I/O is necessary to achieve
> high throughput and efficiently manage resources like threads.
>
> In summary, the following is a list of the tasks in scope for JAX-RS 2.1:
>
> * Adding support for SSE.
> * Improving integration with CDI.
> * Exploring support for non-blocking I/O in providers (filters,
> interceptors, etc.).
> * Evaluating ways in which declarative security can be supported either
> directly in this JSR or by leveraging other EE-platform JSRs.
> * Making JAXB conditional on runtimes where it is available.
> * Providing integration with JSON-B.
> * Building upon the hypermedia API added in version 2.0.
> * Investigating the reactive programming paradigm as a way to improve the
> JAX-RS asynchronous client API.
> * Evaluating any requirements necessary to support the use of JAX-RS
> resource classes as controllers in the MVC 1.0 JSR.
> ===
>
> Some useful links:
>
> [JSR] https://www.jcp.org/en/jsr/detail?id=370
> [JAX-RS Spec] https://jax-rs-spec.java.net/
> [JIRA for 2.1]
> https://java.net/jira/browse/JAX_RS_SPEC/fixforversion/16402/
> [RI] https://jersey.java.net/
> [E-mail Archives] https://java.net/projects/jax-rs-spec/lists
>
> As before, all of our discussions will be conducted using the expert's
> alias and (automatically) CCed to the user's alias.
>
> Some of the 2.1 tasks above require coordination with other specifications
> (JSON-B, Security), so these tasks will tackled later on in the process.
>
> We have tentatively selected 2 topics to start our discussions, both of
> which require some investigation, these are: hypermedia improvements and
> reactive programming. If you have any suggestions/comments/concerns about
> these two topics, feel free to start a discussion about them. We will be
> sending some more info as well in the upcoming weeks.
>
> Looking forward to working with all of you!
>
> --
> Santiago Pericas-Geertsen
> Marek Potociar
> JSR 370 Spec Leads
>
>
>