Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1595
@ptgoetz
That consensus was made with context `breaking change for 1.x`. Sure if we
introduce breaking change in 1.x we need to support the old one. But if we go
on introducing breaking change only for next major version, I don't think we
must follow our consensus.
We even could introduce completely different way like JStorm. In JStorm
metrics are sent to Nimbus, and plugin to external storage is also there, so it
might not be topology specific. In this case we could not provide the
translation shim, but I don't think it matters if we introduce the change for
next major version.
When we talk about new API I'd like to focus the new one, not considering
how to support the old one. For me, this change is more suited to the old one.
There's another level to aggregate, component level, and it might be more
preferred thing. Why I take worker level aggregation instead of component level
aggregation is that it's only possible way to achieve with not breaking current
design. That's why we should not consider about old one while designing new one.
---
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.
---
