On Wed, Oct 12, 2011 at 8:18 PM, Leo Neumeyer <[email protected]> wrote:
> > ... > > > > >> A few thoughts: > >> > >> Input/Output names may not make a lot of sense any longer. What about > >> changing to the following: > >> > >> processEvent(Event1 event) with any of the synchronous configurations. > >> > >> timerTask() called when there is a timer task configured. > >> > >> The timer task needs to be synchronized with the processEvent method > >> (unless the PE has a @ThreadSafe annotation), we can keep the internal > dummy > >> event to synchronize but call timerTask() without an Event instead. I'm > sure > >> there are other ways of doing this. > >> > >> Does this make sense? We need to think a bit. > >> > > > > Indeed, we lose some consistency in the API by handling output triggers > in 2 > > different methods, depending on the trigger (event count based or timer > > based) > > > > The original design (as described in the S4 paper) uses a "processEvent" > > method for input events and an "output" method for triggered outputs. Why > > not just keep that design? For the dynamic overload dispatcher, that > would > > just mean removing the code for "processOutputEvent". > > > > Not sure I understand what you propose. I think we are saying the same: > > the processEvent() method can be configured to be triggered: > > - on every matching input event > - on every N matching input events > - on input event if time since last event is greater than delta > This is a part which is not clear to me. My understanding was that the output method might be triggered at periodic intervals, not the input processing method. You seem to want to mix both methods, which is a bit confusing to me. But it is also possible. > > We still need another method for periodic tasks, maybe a good name is > periodicTask() > is it a periodic task that we need (and we may), or is it a periodically invokable output method? > This method is synchronized with processEvent() (unless PS is > @ThreadSafe) and it doesn't need to pass an event (because it is > asynchronous). > > So it's not just removing processOutputEvent(), we need an additional > method for periodic tasks that is synchronized with processEvent(). > That's the "output" method in the S4 paper, no? Matthieu
