Logging could be done in a round robin fashion where old logs are dropped so one always keeps the latest x logs in the database/cookie. One could also send thelog back to the server if needed.
That way we wouldn’t need alert calls. Especially forgotten alert calls that goes into production.
As I have percieved (all) logging frameworks today work in a synchronous manner. This means that logging comes with a performance impact.
One could create a logging client that sends its entries to a queue. This queue is then fetched by another process. The total processing power required is greater than a synchronous solution and issues might arise when time is a factor. But for the other cases I believe this could be handy.
And one could build a switch into the framework that forces synchronous logging for the times it is necessary.
Then create a log viewer client with more intelligence than just listing text entries. I plan to write about this, but don’t hold your breath.
To start with I am thinking of a message queue. Let the client write to the queue. Then have another process read the queue, possibly from another machine. Let the logging entries be identifiable by a guid. Let the reading process be able to sort these guids to their respective category and present it in a readable way.
Get a spare monitor like a phone or usb and let a program continously show your log with a cool graph. Add sound and a force feedback joystick and it will be more fun than a barrel load of monkeys. All without drawing power from the production machine.