A good companion is: Improving .NET Application Performance and Scalability.
Calum writes his feelings about notifications: they should not have options. And here lies a problems with the view on notifications: am personally not interested in the equivalent to `tail -f some_log'. I want my notifications to be interactive, and hence those options seems awesome.
I am personally interested in a notification framework to the desktop to avoid things like GAIM popping up a dialog box in the middle of writing an email that asks me if I want to accept a buddy or not. In this particular case having a default button makes things worse, because I do not know which people I have accepted or not accidentally. I literally have this problem every day.
In fact, I want to have a log not only of notifications but of actions to follow up to. So some notifications should not go away, they should stick around, and when I have the time I can go and click the appropriate buttons `accept', `accept', `reject', `reject'.
Some other notifications can just go away: if I have not responded to the CD insertion action, it can likely go away from my screen.
Longhorn keeps track of notifications that the user has not seen.
My old gnome-notifier does exactly this, and supports a special kind of url `run:' that you could use to run programs in response to actions.
Elijah Gaim is one of the applications that have this behavior. But even if you do not steal focus, I do not want a window popping up in the middle of the screen for GAIM. I want these kind of notifications to go elsewhere (Windows uses a baloon and the proposals so far are along the same lines: notifications are out of your current work area).
An educational website: Enjoy the Draft Dot Com.
The FAQ is a must-read.
A lighter, more positive side of the draft.
Posted on 22 Oct 2004