boyuanzz edited a comment on pull request #13421:
URL: https://github.com/apache/beam/pull/13421#issuecomment-740162514
> > 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.
We can always unify the implementation details(translating everything into
`TimerFamilySpec`) for timer and timer family since they are not visible to API
users. Some advantages for keeping both `TimerSpec` and `TimerFamilySpec` as
use-faced API are:
* It's clear for API user to know what kind of timers is using.
* It keeps the same terminology as in Java SDK.
@robertwb, are you proposing to use `TimerParam` for both `TimerSpec` and
`TimerFamilySpec` and use `TimerFamilySpec` only in implementation details?
----------------------------------------------------------------
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]
