incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: logging
Date Tue, 14 Mar 2006 00:41:25 GMT
On Mar 13, 2006, at 3:09 PM, Geir Magnusson Jr wrote:

> public interface Monitor {
>
>    public void monitorEvent(
> 	<some type> eventType,
> 	<another type> eventData );
> }
>
> and I hadn't worked out what <some type> or <another type> was.  I  
> figured that you could then add events w/o worrying about clients,  
> because a client would simply ignore any type it didn't know how to  
> handle.  One less thing to worry about when upgrading the kernel.
>
> I thought of a few approaches, such as <some type> == int and  
> <another type> depends on the approach you wanted to take.  Map  
> (for named values), Object[] for a known set of values, or even  
> some base MonitorData which the client could cast to the  
> appropriate type if it understood the eventType, or if not, call  
> toString() or something to get  *something* to put in the log to  
> inform a human that something new was coming out...

I considered this style, but it occurred to me that everyone would  
write a listener containing a switch, which seems like busy work to  
me.  Also, this style event assumes that every event fires the same  
data.

I think the best way to deal with this is to encourage every one to  
extend the NullMonitor which provides no-op implementations of every  
method.  That way they always pickup new methods.

As I wrote before, the biggest issue with using a Monitor is the work  
involved in designing the monitor interfaces.  If they are to  
specific, you don't have upgrade problems, and if they are too  
generic they are difficult to use.  You also need to choose how many  
monitors you need and the granularity.  All of these are very tricky  
issues to get right the first time you write a system.  In XBean, I  
had an advantage as it was the 4th kernel system I've written, so I  
already knew the events users would want to monitor.

-dain

Mime
View raw message