Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/16000
> what is the benefit of force they as one API beside "it sounds correct"?
Because it pretty much ensures that when (not if) we add streaming to the
history server, it will cause breakage in the API and will require a new API
version, which should be avoided.
> i can not think of any usage of history server for streaming application
Maybe you can't, but others can.
I'm sorry you haven't given me a good reason not to implement my
suggestion. What is the real problem with it? The code can still live in the
streaming module. This is completely about where the API is mounted in the URI
namespace, not where the code lives.
Streaming is still part of a Spark application, it doesn't exist by itself.
So providing the streaming API endpoints outside of the application endpoints
is completely inconsistent with the API design.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
