----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> > We seem to be arguing if the handler key should be there
> > or not in the Abstraction.
>
> Precisely.
> The Watchdog interface does not model a manager passed a token/key. It
Handler key was important to me because it allowed n handler to m watchdog
interactions. But if the Watchdog is passed to the handler and it there is
an m handler to n watchdog mapping, the handler ID is implicit.
I see your point...
>
> > > The Watchdog is a just portable, lightweight interface.
> > > If someone wanted to create a Block that provided
> > > Watchdog instances, they could.
> > Would it be possible to provide this as part of the proposal/patch.
>
> Provide what, precisely? A Watchdog Block? I don't see much value to it,
> and I don't want to make the assembly and config files even more complex.
It is a consistency issue . All interfaces etc are registered as services.
A simple watchdog factory registered as a block could do the trick. For
instance
interface WatchdogFactory {
String ROLE = WatchdogFactory.class.getName();
Watchdog getWatchdog();
}
or better have this and remove Watchdog#start.
interface WatchdogFactory {
String ROLE = WatchdogFactory.class.getName();
/** Start the watchdog and have it trigger after @param offset
milliseconds */
Watchdog startWatchdog(long offset);
}
WatchdogFactory could be passed to handlers via config or some other
alternate method.
> OK, now that you've sent your proposed change, I see that your change
> doesn't actually involve a command map abstraction.
I picked the name 'ResettableTimeGuardedCommandMap' from your proposal
subject 'Resetteable Time Guarded Operations'. Replaced Operations with
Command and added Map to indicate m to n semantics.
Never been happy about the name, but did want to not use watchdog or
scheduler word.
> What you did was simply
> rename "trigger" to "execute" on the handler itself, as if one could
> "execute" the handler. Further, since the operation performed was
actually
> semantically an interrupt instead of an execute, it implied the wrong
> semantic.
I put something together fast in the hope we could get talking more about
interfaces.
> Now that I've seen your code in-situ, let's put this into perspective so
> that we all see the difference. We're talking about changing
>
> From: manager = componentManager.lookup(<role>)
[hb]
Or: eventMgr = componentManager.lookup(<role>)
Or: void setEventManager(eventMgr)
Or: eventMgr = config.getEventManger();
> To: void setWatchdog(Watchdog)
>
> From: manager.addX(<arg-list)
[hb]
Or: handlerEventID = add(timeout, this); // handlerEventID is int.
> To: watchdog.start()
[hb] do you mean ?
To: watchdog.start(this)
> From: scheduler.resetTrigger(this.toString())
> Or: eventMgr.reset(handlerEventID)
> To: watchdog.reset()
>
> From: manager.remove(<arg-list>)
[hb]
Or: eventMgr.remove(handlerEventID)
> To: watchdog.stop()
>
> If you want to argue that there should be an Avalon Frameworks interface
for
> these kinds of services, that'd be for the Avalon folks to take up, and
I'm
> sure that Peter and Peter could do something about the service model if
> Peter thought it worthwhile (I'll leave interpretation of the overloaded
> name as an exercise for the reader ;-)).
Good one. :-)
I don't see a big gain in service refactoring, but it looks like James is
getting good performace and you have confidence in it.
Regd. watchdog I still think we should use lookup and block facilities and
not have code like this. abstraction = new AbstractionImpl();
m to n semantics could be done either implicitly or explicitly. Either way
would work but should be there.
Harmeet
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
