what is the aim?

[lbdroid]

First of all, you have a nasty name conflict with the "real" oksse: https://github.com/heremaps/oksse

And second, you seem to be building an SSE library on top of okhttp, which already covers SSE, so why does this project exist? Wouldn't it be smarter to contribute to okhttp?

[AkshayChordiya]

Yeah unfortunately there is a conflict which we came across later, though there were plans to change the name but we couldn't come on an agreement. But I don't see it as a problem plus the heremaps/okssee doesn't seem to be maintained anymore.

OkHttp doesn't cover SSE, which is why if you see heremaps/okssee repository they have also built their SSE library on top of OkHttp.
We thought about contributing to OkHttp but OkHttp isn't a Kotlin Multiplatform yet (it can be but it will require good amount of work) and we wanted to build something generic and re-usable which KMP (Kotlin Multiplatform) offers.

Thanks for reaching out with your concerns. Let me know if you have any further questions.

[lbdroid]

okhttp certainly does cover SSE and I've been using it quite successfully:
https://github.com/square/okhttp/tree/master/okhttp-sse

[AkshayChordiya]

Umm I see, that's good to know. That said the okhttp-sse is still experimental and anyway ultimately it's user's choice if to use this library or okhttp-sse or any other 🙃

The value this library adds is:

1. Kotlin Multiplatform support (the biggest difference)
2. It's not experimental API

[lbdroid]

But wouldn't it be a more useful choice to contribute to upstream?

[AkshayChordiya]

Absolutely if okhttp was Kotlin Multiplatform then we would have 😉 and AFAIK it's not currently in their roadmap