> I wasn't picking on your choosing the name "Thresholdable". > Sometimes I > wonder about the whole "*able" thing for interfaces...:-)
Not to worry, I was picking on my own choice. As long as the name can be said and bring to mind the nature of the behaviour without even looking at the docs, I'm for it. > Yeah, we can make the change to Receivers to implement > Thresholdable. In > fact, I already have. But, my connection to the apache > server has gone down > for some reason and I cannot check in the changes. I'll keep > trying for a > while. If not, I'll check them in tomorrow morning. You can fire the source directly to me if you like and I can put it in. > > And, this is not to say that a "pause" functionality is not > useful at the > plugin level. I am open to it. I could see > pausing/suspending a watchdog > plugin. I'm not sure we need an interface for it, but having some > supporting methods in the plugin interface might still be useful. This is where I am really unclear as to the best way to do it. Interfaces are nice, but in this case, having a pause is almost an 'Optional' operation. A sort of "Gee, it'd be nice if you Plugin developers would implement this, but it's ok if you don't, or it's not appropriate.'. The other, much more techie and hard to read, approach is to have some sort of method tha returns a set/array/Collection of supported Operation enumerated type attributes, sort of like the BeanInfo class does for beans. This way we can extend the # of optional operations in the future and still maintain binary compatability (maybe we still can anyway). Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
