Design decision for logview4net and a new release.


    New year, new release.

    This release incorporates the performance  fixes that were maid last week after some user feedback.

    I still have no intentions to turn logview4net into a full featured log parser, but now it can handle much bigger datasets than before. If I get some bright ideas it might get faster still. The problem is that I load all existing data into the textbox that shows the data. So if you add a file or SQL listener and there is lots of data already there and you choose to show it all; logview4net will treat each row as a separate message and show each message one at a time.

    The design decision I’ve made for logview4net is that all listeners are treated as being forward only data. This means that I can’t get past time data from a listener, it will send new data to the part of the program I call the viewer. The viewer is essentially the textbox that shows all formatted data. This decision was made because I’d rather have lots of available datasources than a fast way to look at old data. logview4net was initially and primarily built to be a real time log viewer/monitor, not a log parser to use on historic data.

    If I only worked with random access data I could take the same approach as Kiwi Log Viewer and load only the data that the use can see at the moment. I have some ideas on how to merge these worlds and I’ll probably use the blog to make them more tangible for myself.

    The changes made to release 8.01 removed lots of processing time when receiving an event but the greediest part is the RichTextBox that comes with the .Net Framework so I’m looking for a replacement for that.