I'm a bit skeptical whether we want to try and tea...

# squarelibraries

[jw]

I'm a bit skeptical whether we want to try and tease out a supertype from websocket that deals with read-only streams

[kevin.cianfarini]

gotcha. What is the reason for the skepticism? I'm curious

[jw]

For one, I'm not sure you'd ever need the actual polymorphism where you can write code that doesn't need to know whether its source was a WS or SSE.

[kevin.cianfarini]

Oh right

[jw]

But beyond that, the OkHttp API of WS doesn't really make it easy to pull out an interface. Each callback takes a WebSocket as the first argument but in SSE you don't really need something to model the WebSocket itself, you only need the listener.

[kevin.cianfarini]

I guess I took what you said to mean that websockets and sse would be implemented completely separately, which seems fine

[kevin.cianfarini]

oh gotcha

[kevin.cianfarini]

does it seem like sse would be easier to pull into retrofit?

[jw]

It may be easier, but it requires a dependency on okhttp-sse which is a bit weird. So it would fail at runtime if you were missing that. Maybe I can get SSE moved into the main artifact like WS.

[jw]

It's fairly small. The problem is very few people seem to use it.

[kevin.cianfarini]

gotcha

[kevin.cianfarini]

yeah it definitely seems like an underutilized feature to me

[kevin.cianfarini]

sse that is

[jw]

both SSE and WS are pretty poor protocols, their benefit is that they're available in browsers unlike something that's superior on a technical level like gRPC

[kevin.cianfarini]

I've never heard of grpc. I'll have to take a look

[jw]

much more heavyweight of a tool, but equally more powerful

[kevin.cianfarini]

I wouldn't be able to use it unfortunately because of lack of browser availability though 😕

[jw]

i think they host a WS-based fallback for browsers