[Tickets #9950] Re: Broken notification in compose window

bugs at horde.org bugs at horde.org
Thu May 5 16:42:38 UTC 2011


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/9950
------------------------------------------------------------------------------
  Ticket             | 9950
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Broken notification in compose window
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-05-05 16:42) wrote:

> And they are raised several times if you had several notifications  
> piling up. Though this might be a problem of audio notifications not  
> being used in the main interface. It makes them pile up, and they  
> are all outputed at once (making a terrible noise) if you open a  
> page that supports audio notifications. I'm not sure if we should  
> implement a duplicate check in the audio notification listener. But  
> for now we should either support audio notifications throughout DIMP  
> or check for duplicates where we output the notifications in DIMP.

I think this issue is more of a fundamental flaw (or, at least, a  
limitation) in the current Notification system.  At present, there  
really is no way to push a notification with the intent of "I want the  
notification to be displayed on this page access and, if not, you can  
go ahead and discard the notification".  Especially for things like  
newmail notifications, this is time-critical information.  It becomes  
useless once the page access is complete.

I've worked around the limitation in IMP (somewhat) by using  
Decorators.  Decorators were used simply because they are triggered  
whenever notify() is called.  Thus, I only create notifications if I  
know the notifications are about to be displayed.

However, an alternative method would be to indicate, at the time we  
are pushing the notification, whether the notification should persist  
in the session.  (Although an advantage of doing the Decorator  
approach is to prevent potentially costly activities, such as mailbox  
polling, when there is absolutely no chance it would be used on a page).






More information about the bugs mailing list