Justification

If the same Django user is logged in twice on different computers simultaneously, they see each others' messages

User messages may get wiped even if they're not actually displayed to the user

High-load sites want to avoid the unneeded database or cache usage

Reasons why a standard needs to be endorsed by Django and a 3rd party app will not suffice:

The built-in implementation is broken for a large set of use cases (above); the fact that Django actively encourages this method of messaging is a bad thing

Reusable apps don't know what 3rd party system to use and hence cannot rely on providing session feedback

Integrating with the Existing API

It is not possible nor desirable to integrate with the existing API because it is tied directly to a related manager on the user model and cannot be extended to support the additional functionality in this proposal (without some ugly hacks). There are several possible solutions to this conflict (we don't really need or want two messaging APIs in the core); feel free to add more:

In the documentation, cast the user messaging API in a vary narrow use; e.g., for administrator messages to specific users

Phase out user messages entirely

Deprecation Plan

The thread on the mailing list seems to be leaning towards deprecating the old API rather than keeping it around in parallel with the new one. If deprecating is the right answer, what follows is a rough plan of how that might play out. Many details are still missing and the plan needs to be fleshed out further in the coming days/weeks.

Django 1.2

Introduce the proposed messaging app

Deprecate the existing API and mark it as such in the documentation. Retain the same functionality.

contrib apps in Django still use the old API

Django 1.3

Update all contrib apps in Django to use the new API

Retain the same functionality in the old API, but raise a deprecation warning when it is used

Django 1.4

Remove the old API. This includes the Message model and any methods in contrib.auth that use it (such as get_and_delete_messages).

Remove the old API from the documentation.

Existing 3rd Party Apps

There are a number of good, pre-existing applications out there that support more robust functionality, so there is no need to re-implement a solution from scratch for inclusion in Django. The existing solutions can be combined or modified to meet Django's needs. This section is meant to evaluate some of the different session/cookie message/notification engines out there for potential inclusion in Django as a contrib app. It is a work in progress so please contribute (your notification engine here) or other changes as you see fit.

Criteria

Technical criteria necessary for inclusion in the core:

Support message passing for anonymous users

Use the session only as a fallback: Avoid database/cache queries if possible, but support larger messages that don't fit in a cookie (> 4kb) when needed

Don't lose messages if they're not displayed to the user (lazy message loading)

Please update this table with new options or corrected information as necessary.

Potential App Names

A number of different names have been suggested on the developers thread and elsewhere. There is a desire not to conflict with the existing '{{messages}}' variable in templates. Some ideas:

notifications

notices

alerts

notes

Potential API

The API is under heavy discussion on the ​django-developers list. The names of variables will be changes to reflect the app name, when one is chosen. Following are a few different iterations of what it might look like:

Pre-configured Message Classes/Levels

Custom message classes may be easily configured for any type of message that does not fit into the pre-set classes, or where more granularity is needed. Consistency is needed regarding what a given class of message means, because multiple, independent Django apps may be combined to form a single project, and consistency is desired in the display of user feedback. It is recommended that reusable apps do not use custom message classes.

DEBUG: Development-related messages that will be removed before a production deployment