Desktop Notifications Spec 0.3

[Mike Hearn]

 > Could I suggest that sound should be mentioned in the spec, as above?
> But emphasising that the use of notification types by the server should
> be the prefered way for the server to choose which sound, if any, should
> be played.

I'm not especially convinced sound as a hint makes any more sense than 
sound as an optional argument to Notify - boils down to the same thing.

I think nobody addressed the core issues with sound:

- Why not do it client side (seeing as apps *already* play sounds async
   with app specific config ui)
- What formats are supported?
- Why have to match notification server with preferred media framework,
   instead of letting the apps decide?

> If it is to be implemented by the server, should an alternative approach
> to the notification types be considered?  As in some sort of hierachy?
> 
> e.g. 
> 
> presence.buddy-online
> presence.buddy-invite
> 
> email.arrived
> email.bounce

This seems to make sense.

> XEmbed:
> Please resist... the benefits of being able to have an all-singing-all-
> dancing notification that a DVD has been inserted into the drive that
> can play the credits sequence in the notification window itself simply
> *doesn't* compare with the benefit of being able to look back at a
> sensible, detailed log of past notifications (which I would expect a
> decent server implementation to provide).

Yeah, I'd agree with this.

The other problems with xembed are that:

- Clients will end up assuming presentation, which we're keen to avoid
- Assumes an X based environment (obviously)

> Screen origin:
> Could you consider specifying that the "screen"/"x"/"y" hints can be
> used to optionally highlight the origin of the notification?  If, for
> example, there is a desktop applet for each attached drive, it would be
> nice for a "Low disk space" warning to indicate by its positioning which
> drive it refers to.  Although it probably has some potential for abuse,
> for some events, relating them spatially to the iconic representation of
> their origin could be useful.

Why not highlight the origin client side? What benefit does doing this 
in server provide? What about multiple screens? Z-Ordering?

> Desktop event logs:
> The potential exists for the notification server to be used as a log of
> "significant" desktop events - could there be an obligatory "nodisplay"
> hint which indicates that the server may log, but may not display the
> notification?

Yes, maybe. What are the use cases though?