The thing that sucked me in the most about your idea is the channels, and with the ability to name channels however you'd like, there are potentially infinite channel names (ok, pedantically, it only approaches infinity; I assume there is a character limit for the channel names). I imagine being able to create a channel for, perhaps, different network device types, say, Cisco Routers, and another for, say, Nortel Switches, and yet another for Checkpoint Firewall routers.

Changing hats, as a server guy, I could create my own set of server channels keeping track of resources like drive space, memory, cpu usage; and changing hats again, as an application developer/baby-sitter, I can create channels for the interoperation of various applications that all work together, etc.

Now some of these abilities are already in syslog, but we're pretty limited in the number of channels we can use, so trying to coordinate between all the groups to agree on the "standards" to keep from "poluting" one anothers syslog files could get pretty ugly.

I also like the relatively light weight for the "broadcast" ability of the syslog information. I'm not very familiar with the actual IRC protocol implementations, but way back when, I think I recall that if you wanted to create an IRC 'server', that server just had to ask (and receive permission) to receive the IRC messages; and similarly a client simply had to ask a server to be able to receive the appropriate messages. This seems to be fairly light weight, and things are even better if IRC now can actually use multicasting.

++ many times for this very cool idea.

-Scott