On Sun, Aug 10, 2008 at 7:05 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote:
> For Growl we register two notification types. The way, from the Growl > preference panel you pick a notification type and turn it off, make it > sticky, add a sound, etc. It works because type is not an open-ended > list, Growl knows all the notification types we'll ever send. Yes, got that. I must say, this kind of design reminds me of the Windows Registry central command-and-control :) If there's a good reason for having a third notification type we can > register it; if there's a use case we'll know what the API should look > like to add it. Otherwise we're prematurely abstracting the API and > in doing so actually making Growl less useful. The original > implementation was not lack of foresight, but designed to only provide > what is necessary and use it to maximum effect. I was thinking about notifications such as Jetty started, application deployed, etc. Basically, the sort of situations where a human could be waiting for the completion of a task to take over manually. > Separately, Object is a really bad kitchen sink. Methods that enter > Object need to justify their inclusion, not be there imagining someone > would one day maybe opt to use them. If something gets used a lot, > you want to make it easily accessible: warn, trace, info are something > we want to encourage people to use. I don't see a use case for pop up > notifications that would justify polluting Object. Yes, I was myself a little worried about namespace pollution. I've removed notify() from the global scope until we settle on the use-cases. alex
