Since Scott has said that he would help with maintenance and Rob T has also indicated that he would perhaps help, this is my view of the current status of Chainsaw and what I feel its current deficiencies are.
Current status: Master builds and mostly works. The last thing that I had been working on was updating the config files in order to remove xstream and better standardize on using commons configuration. I think some of the configuration settings don't save/load correctly, but some do. All of log4j1 has been removed. Certain features have been removed too that were largely dependent on log4j1. What I feel would be useful for Chainsaw: For me, I do a lot of embedded work. Most of the log files that we have at my current job just go to syslog on our device(syslog is provided by busybox). So viewing logs is a matter of SSHing into the system and just reading from the buffer. Having a utility running on a separate computer that lets me see the logs(especially if it can connect automatically to a device) could be very useful. Specific potential use-case: at my last job, I wrote a quick log viewing utility that would correlate log messages between two separate devices. This was needed because one device was embedded that logged out the serial port, the other was Linux and would log over the network, but neither had reliable time. Current limitations that I find with Chainsaw: The current GUI is not very useful. A large portion of the screen is taken up by toolbars/context information that I generally don't find useful. I think most of the features that are in the GUI are very useful(for example, being able to trace messages and add matches) but is limited by the fact that I only see a small portion of the context at a time. In my mind, an ideal solution would be to get rid of the toolbars as much as possible and to focus more on the log messages like you would see in a terminal, but still having the capability to right-click on a message/message components and investigate individual messages or flag them appropriately. Perhaps the best way to organize this would be to have a logical split in the code: the backend(which receives and routes log messages) and the front-end portion. The front-end could be something like Swing for a GUI, or some sort of command-line interface like ncurses. Thoughts? What is something that people want to see/think could be useful/would want to try and code up? -Robert Middleton
