ElmahR persistence, and what about documentation?
My work on ElmahR is going on, during the last few days I've been adding useful features which I'll describe here briefly. Then I'll spend a few words about what's going to become more and more important very soon: documentation.
Persistence
Up to version 0.6 ElmahR dashboard life cycle was strictly related the the web application life cycle itself. As soon as the server was starting receiving error notifications, it would just accumulate them in memory. New clients connecting would therefore be able to receive 'old' errors only if still in memory on the server application. We all know that web applications can (and should) be recycled every now and then, that means that old errors can go away any moment. My idea about what ElmahR is has always been about a 'realtime' notification system, but it's true that a (short) historical time window can be useful, especially in the event of reconnections. We cannot trust the server application itself, so we need a system to recover historical errors. One way would be to go directly to the monitored applications, ELMAH gives us at least a couple of ways to look at old errors, so we could ask those details, but it's true that most of the times those kind of endpoint could be secured and not easily availables. So I decided to go the other way, implementing a persistence mechanism on ElmahR side.
The 'in memory' persistence was already implemented as a specific 'module', so it's been actually quite easy to build a new one persisting errors on a database table, which can be selected through configuration. To implemented I decided to go with Entity Framework, which is actually like using a bazooka to kill a mosquito :) I know that, the persistence here is really simple and it needs just one table with a bunch of columns, it would have been really easy to go with plain old ADO.NET or some simple data access library, so why use a fulll fledged ORM when I don't really have 'entities' to handle? I asked myself all those questions, but then I thought that this project is also a playground for me, and I was quite curious about using Code First and Migrations, so I gave them I try. It's been really easy and quick to implement the data access and I had the persistence up and running in a couple of hours, so I'm happy with my choice so far, knowing that there's always time to adapt this piece to another strategy.
Persistence actually helped to improve an already, but still quite new, existing feature which allows a user to ask for older errors on demand. On first connection ElmahR sends the last 25 errors he received, and the user can decide to ask for older errors, again in chunks of 25 messages. The previous 'volatile' persistence mechanism was not consistent across multiple connections, but now with more 'stable' historical data this feature works much better. Just scroll the page down to the bottom of the main errors feed and you will see how to ask for older errors. Check it out here.
Documentation
So we've reach version 0.7, there are still a lot of things to do but what's there starts being quite solid, with a number of features that I think makes ElmahR worth a try. What's really missing now is some more consistent documentation to actually implement a solution based on ElmahR. I've been blogging quite a lot about it, describing technical aspects of the project and showing configuration samples, but those info are not really organized in a way a user can easily and quickly go through them and figure out what's needed in order to have ElmahR up and running with no pain. So that's my next step, write some simple and straightforward docs to help you out there using ElmahR along with your applications. Stay tuned here and on the repo :)