Support for server sent events

[abhishekjamloki]

Hello,
I am trying to consume the following using retrofit

https://mesosphere.github.io/marathon/docs/rest-api.html#get-v2-events
I could not find a suitable command/documentation for consuming server sent events. Does retrofit currently support it ? If not is it on the roadmap for future releases.

Thansk!

[caseykulm]

http://square.github.io/retrofit/javadoc/retrofit/http/Streaming.html

Also #568

Also https://github.com/square/retrofit/releases/tag/parent-1.6.0

So basically annotate your @GET("/v2/events") with @Streaming as well.

[JakeWharton]

We don't offer a way to handle this automatically including deserialization of these events (usually people wanting this use websockets which we do plan to support). That said, I'm pretty sure there's a way to hack a CallAdapter and Converter pair together to make this work. I'll have to give it a go some day this week and see what I can come up with.

[JakeWharton]

Spec https://html.spec.whatwg.org/multipage/comms.html

Info:

• http://www.html5rocks.com/en/tutorials/eventsource/basics/
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
• http://caniuse.com/#feat=eventsource

An interesting spec. The "data:" prefix seems wasteful, but hopefully no one has a newline-laden message body. I would have preferred a series of length-prefixed, opaque binary payloads for the message bodies.

[JakeWharton]

Been thinking about this for a while, and I have an idea of the approach I want to take when I get around to implementing. Merely writing it down so I don't forget when I come back to this post-beta2.

The semantics of Call prevent reusing its type for this, and that's probably a good thing since it fundamentally (sort of) differs from a one-shot request/response exchange. Another type will be introduced (likely in a sibling artifact) for representing SSE calls. For the purposes of discussing it, we'll name it EventCall.

There will be an EventCallAdapterFactory which needs registered with Retrofit.Builder. It will match the EventCall return type on service methods. It will require the @Streaming annotation be present on the method. Unlike a normal CallAdapter.Factory, it will cache the response type in its created CallAdapter, but return ResponseBody from responseType(). This, combined with the required @Streaming annotation will allow the CallAdapter instance effective access to the streaming socket.

EventCall will be parameterized just like Call and as previously mentioned that response type will be cache, but not exposed. A Converter will be obtained from the Retrofit instance for the response type which will be used for deserializing each server-sent message. It is the responsibility of this converter to deal with variance in the message types. That is, only one type will be exposed and if the user wants different message types then a common superclass of interface must be used and some other means of casting in user-code to the right type.

When a ResponseBody is received its source() will be wrapped in a custom Source that exposes the individual messages as single Source instances that can be wrapped up in their own ResponseBody instances, passed to the Converter, and the resulting object fed back to the user. This is will be similar to how websockets work in OkHttp.

EventCall will expose an asynchronous method. It takes a callback, very similar to Call, except that the successful callback will be called once for each event. It's not clear whether synchronous is useful here as it undermines the transport mechanism (by providing something like an Iterator<T>), but perhaps there's room for synchronous connection and then attaching the callback?

RxJava integration lends itself well to this model, but having this ship as a separate artifact creates an unfortunate wannabe-love-triangle of dependencies that prevent the simple integration. Since we have no way of differentiating Observable<T> for normal request/response and Observable<T> for SSE we'll probably need a method-level annotation to denote, which will lend itself to the separate artifact anyway, but resulting in the need for this CallAdapter.Factory to be registered before the normal RxJava one. But this can be figured out after all the aforementioned things are integrated.

[kgpmurray]

Is this still in the pipeline? If so do you have a rough timetable for release?

[JakeWharton]

No timeline. Unsure if we'll ever support it natively.

On Wed, Aug 17, 2016 at 12:03 PM Keith Murray notifications@github.com
wrote:

Is this still in the pipeline? If so do you have a rough timetable for
release?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1029 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEcQWhLkyqXqKzZw2LZnkLB53nhEkks5qgzDRgaJpZM4FxUsd
.

[RyanRamchandar]

There is one other Android library which handles Server-Sent Events found here:
https://github.com/tylerjroach/eventsource-android

Having this integrated in Retrofit2 would be convenient.

[marcelpinto]

@RyanRamchandar we did an implementation, is still under development and we need to change few things, but you can use it as a reference.
https://github.com/heremaps/okhttp/tree/master/okhttp-sse