Hi Sebastian,
thanks for your feedback!
Ad Subscriber - I consider that as part of the "cleanup" phase - we
could introduce some fluent builder or something like that for
subscribers. But there is one thing, which is not exactly correct -
users cares about 2 methods, or maybe even 3:
- onNext
- subscribe (user needs to call subscription#request(int) to start
receiving events)
- onComplete (user usually wants to know when the events processing is
done.)
- onError should be good practice to have as well.
But I agree that JAX-RS API shouldn't force everyone to create SAME
AbstractSubscriber - and we need to see whether it would be the same or
not..
Thanks and regards,
Pavel
On 28/01/2017 11:49, Sebastian Daschner wrote:
>
> Hi Pavel,
>
> some feedback -- after rewriting my examples I did for the Java
> Magazine article last year:
>
> I like the change on the SseBroadcaster, it makes the code leaner.
>
> The new Subscriber model on the client side is IMO more cumbersome to
> use. The examples declare their own AbstractSubscriber, even if
> they're just interested in #onNext. Visible when you look at the
> changes of SseClient in b2b8f3f. IMO we should a least provide
> shortcuts to the client.
>
> Cheers,
> Sebastian
>
>
> On 01/24/2017 08:54 PM, Pavel Bucek 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 SseBroadcasterextends AutoCloseable, Flow.Publisher<OutboundSseEvent> {
>> //...
>> }
>>
>> could be modified to
>>
>> public interface SseBroadcasterextends 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
>>
>