0.5 Notification Summary

We have a cluster of open issues around notifications that we'd like to resolve in .5

Problems and open issues

• We have multiple notification mechanisms that appear to have some overlap:
  • NotificationFramework, used by:
    • Task scheduling (we may want to rethink task scheduling and make use of the twisted framework)
    • Cpia events (although we think the current notification mgr might be overkill for this use)
  • Notifications in the repository, used by:
    • ItemCollections/queries
  • Inter-thread lightweight notification, used by:
    • sharing service notifications to ui
    • email service notifications to ui

• We ought to make some decisions about the notification frameworks. A few options:
  • improve the existing NotificationFramework and try to use it everywhere?
  • decide we really want multiple systems because they serve slightly different needs?

• Issues with NotificationFramework:
  • subscription is required, sort of high overhead
  • subscriptions don't persist, so overhead of subscribing needs to happen each time
  • current uses aren't really taking advantage of its features, we currently don't use multiple subscribers
  • doesn't currently support notifications across threads

• Issues with inter-thread notifications:
  • Email and sharing services notify the ui directly, breaking the layered architecture (and preventing us from being able to run a "headless" chandler)
  • We might want to broadcast notifications from email and sharing services
  • This mechanism might be more approprate for cpia events than using the NotificationFramework

• Issues with repository notifications:
  • We'd like to support "instant update" when items change as well as when item collections change

Engineering suggestions for Notification Manager .5

• Should be able to choose to deliver the Notification Asynchronous or Synchronous
• Should be able to register a group of Notifications then be able to unregister one or more later
• Should be able to persist Notifications as well as register and unregister during the the Application lifecycle
• Should be able to send Notifications across Threads (each Thread would need a Queue)
• The Repository would keep its current callback mechanism and the Notification Manager would register callbacks with the Repository and server as a broker between Application / Services layers and the Repository
• Ted suggested that the Service layer implement callbacks that the Notification Manager could register against. The issue is the amount of unneeded chatter this might produce.

Engineering issues for Notification Manager .5

• Calling a method on an item only good in the view it was created in
• What layer should the Notification Manager live in (Services, Application)
• Do we even need complex Notification Manager or are callbacks sufficient?

Initial Plans for .5

• Look at ways to call across Threads and implement a Thread Queue in Python
• Look at Repository callback API
• Look at what Asynch mechanism we might leverage (Twisted)
• Come up with a high level written proposal and meet with Engineering team to discuss

Misc Questions

* Do we take into account our ideas for using XMPP notifications for server-> client notifications as well as client->client? Or is that gold-plating at this point? --Lisa

-- KatieCappsParlante - 26 Oct 2004