After some skype we converged to the following: We support synchronous and asynchronous method triggers. The synchronous trigger is activated when an input event arrives and the asynchronous one is triggered by a timer.
Proposed solution: * Synchronous methods: Signature: processEvent(SomeEvent event) Default behavior: trigger on every event Configuration: configure triggers by Event type, synchronized with all processEvent() and periodicTask() methods unless PE is annotated with @ThreadSafe * Asynchronous method: Signature: periodicTask() Default behavior: no trigger Configuration: interval in time unit, synchronized with all processEvent() methods unless PE is annotated with @ThreadSafe -leo On Thu, Oct 13, 2011 at 7:21 AM, Matthieu Morel <[email protected]> wrote: > 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 > -- -leo
