Autodirective sound capture: towards smarter conference rooms

this kind of activity. The two most important have proved to be logging and general object-state access. Logging. I can't argue strongly enough for our object-network OS to support a ubiquitous, low-impact logging facility. It's equally important that object implementations are fully instrumented with log output and that such instrumentation never be removed. Once a system is having a problem, it's too late to think about adding logging to the code. We have had many complicated and hard-to-reproduce problems what I'll call nth-order feedback classes of problems such as oscillation. Without the ability to snoop around and watch log activity, problems would be nearly impossible to diagnose. Using our project's implementation as an example, let me describe what I think are the key aspects of a suitable logging facility. First, it is very useful to classify log-record output hierarchically. Typically , there would be classes and subclasses for maintenance, error, warning, and trace kinds of output. From the programmer's perspective, the logging primitives should be right there as part of their programming model and runtime environment. We keep a store-and-forward log facility object on each machine, whose job is to very quickly buffer local log activity into a disk-based FIFO queue, then forward that queue's content asynchronously to another facility (typically a central store that can be monitored on the fly). In addition , we can turn on and off different levels of log output at the object-instance level. Typically, our system runs objects with all trace output turned off, but if we're tracking down a problem we can reach in while an object is instantiated and modify its output log filter. This approach has proven essential in our system. Without such logging facilities, a system even an order of magnitude smaller would be impossible to operate. General object-state access. The ability to probe the general state of an object instance while it's instantiated is also very useful. If we think about the general nature of the objects within our object-network OS, we see a high degree of common behavior. For example, any object can publish and subscribe to properties, listen for events, or reference and be referenced by other objects. In our implementation, this list of common traits is even longer. It would be very nice to be able to ask any object in the system to dump its current state. As with logging, this kind of facility is …