apache
HTTPCLIENT-2396 - add Server-Sent Events client to HttpClient5.
New SSE module for HttpClient5 with EventSource, SseExecutor, and spec-compliant parsing.
Pluggable reconnect strategies, resumable IDs, and Retry-After hints; H1/H2 ready.
Defaults are simple; advanced tuning exposed via builders and strategies.
Includes docs, examples, and tests; API surface ready for review.
@arturobernalg Would it be OK for you to move implementation classes to impl package? It would make it easier to focus on the publicly visible APIs.
@arturobernalg What is your motivation for proposing this new module? Do you have an application that would be using it? Is there any chance of someone else contributing to it as well?
That would be the second module where you would be the sole maintainer.
@arturobernalg What is your motivation for proposing this new module? Do you have an application that would be using it? Is there any chance of someone else contributing to it as well?
That would be the second module where you would be the sole maintainer.
My motivation is to provide minimal, low-level support for Server-Sent Events on top of the existing async HttpClient APIs. Right now users who need SSE either implement their own ad-hoc parsing and reconnect logic, or pull in a separate client library.
I do have concrete use cases for this in long-lived monitoring / event streams and would use this module in those applications instead of maintaining custom SSE code.
The module is small, self-contained and builds only on existing HttpClient primitives. The public API is intentionally limited, so the maintenance cost should stay low even if I remain the primary maintainer.
@arturobernalg Would it be OK for you to move implementation classes to
implpackage? It would make it easier to focus on the publicly visible APIs.
I don't recommend doing this. Package-private (default) visibility is the only reliable Java language mechanism we have to encapsulate implementation details. If we put implementation details in an impl package, they all need to be declared public just so we can make internal calls to them from our actually-public APIs!
