y1chi commented on pull request #13421:
URL: https://github.com/apache/beam/pull/13421#issuecomment-738456716
> Rather than having a parallel path for TimerSpec and TimerFamilySpec
throughout the whole stack, could we have only TimerParam right at the top
which translates everything to a TimerFamilySpec and treat everything as timer
families from there on?
yeah I think the main consideration is what Boyuan commented, and also
whether we should unify the API of RuntimeTimer vs. RuntimeTimerFamily. For
RuntimeTimer previously we don't offer an API such as timer.get('tag').set() or
timer.get('tag').clear() as we need for the dynamic timer. If we unifies APIs,
we'll always have a dynamic timer and it offers such APIs to have backward
compatibility:
- get('tag').set()
- get('tag').clear()
- set()
- clear()
To me having set() and clear() directly on a dynamic timer (and implicitly
using empty tag) can be a little bit confusing.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
