Version 13 (modified by Tobias McNulty, 15 years ago) ( diff )

add 'avoids pickling' to list of criteria

Message Passing For Anonymous Users

Proposal for 1.2: Django should include a contrib app, independent of contrib.auth, that facilitates message passing to anonymous users.

For more information see:

Justification

Reasons why an alternative to the existing functionality (user.message_set.create) is needed:

  • It's not possible to create messages for anonymous users
  • 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

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

Criteria necessary for inclusion in the core:

  • Support message passing for anonymous users
  • Avoid database/cache queries if possible
  • Support larger messages that don't fit in a cookie (> 4kb)
  • Don't lose messages if they're not displayed to the user (lazy message loading)
  • Signs cookie-based messages
  • Avoids pickling because of the obvious security concerns
  • Provide a standard, intuitive interface so that reusable apps can provide feedback related to the current session
  • Needs community approval/support
  • Needs to be the "de facto" standard implementation

Available Options

Name and LinkAnonymous user supportMinimal DB AccessSupports messages > 4kbLazy loads messagesSigned cookiesAvoids picklingStandard interface
django-notifyyesyesyesyesyesnoyes
django-flashyessometimessometimesnoyesnono
django-flash-statusyessometimessometimesnoyesnoyes
django-cnotesyesyesnonoyesnoyes
  • yes means yes, always
  • sometimes means under certain conditions (e.g., an engine might support large messages if the session is used, and avoid DB access if a cookie is used, but not both)
  • no means no, not in the current implementation

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

Note: See TracWiki for help on using the wiki.
Back to Top