Hi Sergey,
that was my plan, but it got postponed because most of the people were
requesting more time for the review. But now it seems like we won't get
much more. We are discussing some additional improvements - we will
share them either later today or tomorrow.
We will definitely do the m04 build, most likely during next few days.
There is an EDR which we need to push out soon (more details will follow
later).
Will keep you updated.
Pavel
On 08/02/2017 12:19, Sergey Beryozkin wrote:
> Hi Pavel
>
> And also, can you please consider creating a m4 milestone release for
> Maven Central in the next week or so ? We'd like to try to migrate a
> m01 SSE implementation code to the latest one and check, along the
> way, what else can be improved etc
>
> Thanks, Sergey
> On 05/02/17 21:42, Adam Bien wrote:
>> Hi Pavel,
>>
>> your suggestion to use Java 9 Flow API sounds good. Flow looks good
>> to me.
>>
>> Regarding the idea of "Adapter" classes for Java 9 support -- it is a
>> pragmatic approach.
>>
>> Are you actually implementing a PoC in parallel with the API? Does
>> the current Jersey "master" branch already reflect your API proposals?
>>
>> cheers,
>>
>> adam
>>> On 24 Jan 2017, at 20:54, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
>>>
>>> Dear experts,
>>>
>>> please allow me to bring up another addition planned to be included
>>> in JAX-RS 2.1: Support for Server Sent Events.
>>>
>>> The API was introduced a while back [1], but we did incorporate some
>>> changes, mostly alignments with Java SE 8 and another one, slightly
>>> more controversial - alignment with Java SE 9 Flow API.
>>>
>>> Why we should use Flow API? We want to make the transition to Java 9
>>> as smooth as possible. Please note that today, the JAX-RS sources do
>>> contain Flow class (1:1 copy from Java SE 9), but that is NOT a
>>> final state. We want to work with it as much as possible, but we
>>> will minimize and clean up the code before final release. How?
>>> Consider following example:
>>>
>>> public interface SseBroadcaster extends
>>> AutoCloseable, Flow.Publisher<OutboundSseEvent> {
>>> //...
>>>
>>> }
>>>
>>> could be modified to
>>>
>>> public interface SseBroadcaster extends
>>> AutoCloseable {
>>> //...
>>> void subscribe(SseSubscriber<? super
>>> OutboundSseEvent> subscriber);
>>> }
>>>
>>> I hope you will like the attempt to be "forward-compatible", but I
>>> assume that this proposal alone will bring some opinions - please
>>> share them! Last note: currently, the Flow API is used only in SSE.
>>> We plan to use it heavily in Non-blocking I/O. If you think there
>>> are other areas where we can take advantage of Subscriber/Publisher
>>> methods, please let us know.
>>> Let me get back to the SSE API.
>>>
>>> Very brief description of the API is on the wiki [2], I will expand
>>> that once we'll have some feedback.
>>> The proposal contains support for server and client side. All
>>> classes are in the package javax.ws.rs.sse [3]. There is no added
>>> class from the last proposal, but there are some changes:
>>>
>>> - [server] SseBroadcaster extends Publisher<OutboundSseEvent>
>>> - [server] replaced SseBroadcaster.Listener by
>>> SseBroadcaster#onException and SseBroadcaster#onClose
>>> - [server] SseEventOutput extends Subscriber<OutboundSseEvent>
>>> - [client] SseEventSource extends Publisher<InboundSseEvent>
>>> Corresponding commit [4] looks like a bigger one, but most of it is
>>> renaming based on introduced interfaces, the core of the change is
>>> relatively small.
>>>
>>> I look forward to your comments and suggestions.
>>> I don't want to prolong this already too long email - please let me
>>> know if there are some areas which I should describe in more detail.
>>>
>>> Thanks and regards,
>>> Pavel & Santiago
>>> [1]
>>> https://java.net/projects/jax-rs-spec/lists/jsr370-experts/archive/2015-10/message/28
>>> [2] https://java.net/projects/jax-rs-spec/pages/ServerSentEvents
>>> [3]
>>> https://github.com/jax-rs/api/tree/master/jaxrs-api/src/main/java/javax/ws/rs/sse
>>> [4]
>>> https://github.com/jax-rs/api/commit/b2b8f3f4f20696558a3ff52b0de17fb04c343d02
>
>