In the spirit of Russell's No! Bad Pony! talk at DjangoCon I'd like to
start a conversation about cleaning up session messages enough to get
them into core or contrib. Alex suggested that the ticket (http://
code.djangoproject.com/ticket/4604) was not the right place for the
conversation so I'm starting one here.
There are a number of usable solutions out there but django-notify is
the most complete, polished one that I know of. I just contributed a
patch for combo/fallback storage, a version of which SmileyChris
integrated into trunk (of django-notify, not django). It's a solid
product with well-commented code and a good test suite.
What needs to be done to get this or something like it into contrib?
On Fri, Sep 11, 2009 at 01:00, Tobias <tobias.mcnu...@gmail.com> wrote: > There are a number of usable solutions out there but django-notify is > the most complete, polished one that I know of.
I've just tested django_notify, so far it seems plenty good enough to replace all my pass-on-message hacks (not to mention being much more elegant than any of 'em) expect for not being able to set a message php-style in the GET, this way:
On Fri, Sep 11, 2009 at 7:00 AM, Tobias <tobias.mcnu...@gmail.com> wrote:
> In the spirit of Russell's No! Bad Pony! talk at DjangoCon I'd like to > start a conversation about cleaning up session messages enough to get > them into core or contrib. Alex suggested that the ticket (http:// > code.djangoproject.com/ticket/4604) was not the right place for the > conversation so I'm starting one here.
> There are a number of usable solutions out there but django-notify is > the most complete, polished one that I know of. I just contributed a > patch for combo/fallback storage, a version of which SmileyChris > integrated into trunk (of django-notify, not django). It's a solid > product with well-commented code and a good test suite.
> What needs to be done to get this or something like it into contrib?
Since you were evidently at my DjangoCon presentation, you know that I (and the core in general) have a pretty high level of reticence to adding things to contrib - especially when the package can live quite happily outside of core. So far, everything I have seen about django-notify/djangoflash makes it seem like a completely standalone package that will gain nothing from being part of core, other than increasing the size of the tarball, and increasing the maintenance load of the core team. One of the questions that needs to be answered is "why should this be shipped with Django?"
Packages also need to meet the basic definition of django.contrib in order to be accepted. Part of this definition is that it must be the defacto standard implementation. In order to be the defacto standard implementation of anything, it needs to be relatively stable and feature complete. When you make statements like "I just contributed a patch for combo/fallback storage", it leads me to believe that this may not be the case - at least, not yet.
You also mention that there are a number of other implementations, but you haven't really given a compelling survey or analysis of the alternatives - you've just blessed one in particular. Why?
Another piece of the puzzle that is missing from my perspective is any discussion of how session-based messaging interacts with the existing contrib.auth messaging framework. IMHO, Django shouldn't ship with two messaging APIs, so what is the integration point? Do we need a messaging backend API? I haven't thought about this problem anywhere near enough to offer a proposal, but I haven't seen any discussion of this point either. A good solution for this problem would go a long way to greasing the wheels.
> One of the questions that needs to be answered
> is "why should [a session based notification system] be shipped with Django?"
> Another piece of the puzzle that is missing from my perspective is any
> discussion of how session-based messaging interacts with the existing
> contrib.auth messaging framework. IMHO, Django shouldn't ship with two
> messaging APIs, so what is the integration point?
Having some kind of defacto cross-request notification system makes
sense; it's a very common usage pattern.
Attaching these kind of messages to a User instance is wrong: there is
not an enforced one to one correlation between a user and a session
[1], and you can't notify anonymous sessions.
The current contrib.auth messaging framework can't be removed or
replaced while keeping full backwards compatibility. A basic user
based messaging system still has it's uses, but it is not the best fit
for session notifications.
Side note: a pet peeve of mine is that contrib.auth messages are not
lazily loaded, which means you get a db hit every request [when using
a RequestContext] and lose your messages whether you use the messages
context var or not, but this is a side issue and should probably be a
ticket of it's own.
For some background, I initially started 4604 much more tightly
coupled with core, and one which backwards-compatibly worked with the
current user-based messaging system. Malcolm specifically requested
that this should be written as a stand-alone contrib app rather than
part of core, and that it should have minimal impact on existing code.
On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@gmail.com> wrote:
>> One of the questions that needs to be answered >> is "why should [a session based notification system] be shipped with Django?"
>> Another piece of the puzzle that is missing from my perspective is any >> discussion of how session-based messaging interacts with the existing >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two >> messaging APIs, so what is the integration point?
> Having some kind of defacto cross-request notification system makes > sense; it's a very common usage pattern. > Attaching these kind of messages to a User instance is wrong: there is > not an enforced one to one correlation between a user and a session > [1], and you can't notify anonymous sessions.
> The current contrib.auth messaging framework can't be removed or > replaced while keeping full backwards compatibility. A basic user > based messaging system still has it's uses, but it is not the best fit > for session notifications. > Side note: a pet peeve of mine is that contrib.auth messages are not > lazily loaded, which means you get a db hit every request [when using > a RequestContext] and lose your messages whether you use the messages > context var or not, but this is a side issue and should probably be a > ticket of it's own.
> For some background, I initially started 4604 much more tightly > coupled with core, and one which backwards-compatibly worked with the > current user-based messaging system. Malcolm specifically requested > that this should be written as a stand-alone contrib app rather than > part of core, and that it should have minimal impact on existing code.
Sorry - perhaps I need to be more clear on my intent here. I'm convinced of the importance of session-based messages - just not of when and how a particular implementation should be added to trunk.
I agree that they are a useful idea. I agree with Malcolm that session based messages should be a standalone app. I don't think they should be tightly bound to core.
What I'm talking about is an orthogonal set of modifications that would allow for _any_ messaging system (database backed, session backed, or magic pony backed) to be used. This doesn't couple a particular implementation of session-based messages to the core, but it would allow for end-users to choose a session-based message framework if they found one that was appropriate to their needs. In the fullness of time, we may end up adding django-notify or similar to contrib, but if we add the plugable backend we can defer that decision until much later when implementations have stabilized and a clear implementation winner has emerged.
If such an abstraction API isn't possible (and the differences between the capabilities of the two certainly makes this likely), then that makes it even more important that we choose the right implementation to add to contrib. As it stands, I'm aware of at _least_ two implementations (django-notify and djangoflash), but I have no real feel for the implementation maturity or general level of community acceptance of either. I'm not going to advocate adding anything to contrib until I can be convinced that one particular implementation really is the defacto standard implementation of the pattern.
> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@gmail.com> wrote:
> >> One of the questions that needs to be answered
> >> is "why should [a session based notification system] be shipped with Django?"
> >> Another piece of the puzzle that is missing from my perspective is any
> >> discussion of how session-based messaging interacts with the existing
> >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two
> >> messaging APIs, so what is the integration point?
> > Having some kind of defacto cross-request notification system makes
> > sense; it's a very common usage pattern.
> > Attaching these kind of messages to a User instance is wrong: there is
> > not an enforced one to one correlation between a user and a session
> > [1], and you can't notify anonymous sessions.
> > The current contrib.auth messaging framework can't be removed or
> > replaced while keeping full backwards compatibility. A basic user
> > based messaging system still has it's uses, but it is not the best fit
> > for session notifications.
> > Side note: a pet peeve of mine is that contrib.auth messages are not
> > lazily loaded, which means you get a db hit every request [when using
> > a RequestContext] and lose your messages whether you use the messages
> > context var or not, but this is a side issue and should probably be a
> > ticket of it's own.
> > For some background, I initially started 4604 much more tightly
> > coupled with core, and one which backwards-compatibly worked with the
> > current user-based messaging system. Malcolm specifically requested
> > that this should be written as a stand-alone contrib app rather than
> > part of core, and that it should have minimal impact on existing code.
> Sorry - perhaps I need to be more clear on my intent here. I'm
> convinced of the importance of session-based messages - just not of
> when and how a particular implementation should be added to trunk.
Thanks for your clarifications.
> What I'm talking about is an orthogonal set of modifications that
> would allow for _any_ messaging system (database backed, session
> backed, or magic pony backed) to be used. This doesn't couple a
> particular implementation of session-based messages to the core, but
> it would allow for end-users to choose a session-based message
> framework if they found one that was appropriate to their needs. In
> the fullness of time, we may end up adding django-notify or similar to
> contrib, but if we add the plugable backend we can defer that decision
> until much later when implementations have stabilized and a clear
> implementation winner has emerged.
django-notify is built on a pluggable backend architecture.
It comes with packaged with three backends, and custom backends are
also supported.
> As it stands, I'm aware of at _least_ two
> implementations (django-notify and djangoflash),
I agree, the decision is important to get right.
To clarify, django flash is actually more than just a session
notification backend, it introduces a whole new temporary (but cross-
request) variable scope.
Leah has a messaging implementation which uses django-flash:
http://github.com/leah/django-flash-status
So the question changes into, "are we after just a notification system
or do we want to have a more open (but arbitrary) system of a
temporary cross-request variable scope?"
On Sun, Sep 20, 2009 at 11:30 PM, Chris Beaven <smileych...@gmail.com> wrote:
> On Sep 21, 12:05 pm, Russell Keith-Magee <freakboy3...@gmail.com>
> wrote:
>> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@gmail.com> wrote:
>> >> One of the questions that needs to be answered
>> >> is "why should [a session based notification system] be shipped with Django?"
>> >> Another piece of the puzzle that is missing from my perspective is any
>> >> discussion of how session-based messaging interacts with the existing
>> >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two
>> >> messaging APIs, so what is the integration point?
>> > Having some kind of defacto cross-request notification system makes
>> > sense; it's a very common usage pattern.
>> > Attaching these kind of messages to a User instance is wrong: there is
>> > not an enforced one to one correlation between a user and a session
>> > [1], and you can't notify anonymous sessions.
>> > The current contrib.auth messaging framework can't be removed or
>> > replaced while keeping full backwards compatibility. A basic user
>> > based messaging system still has it's uses, but it is not the best fit
>> > for session notifications.
>> > Side note: a pet peeve of mine is that contrib.auth messages are not
>> > lazily loaded, which means you get a db hit every request [when using
>> > a RequestContext] and lose your messages whether you use the messages
>> > context var or not, but this is a side issue and should probably be a
>> > ticket of it's own.
>> > For some background, I initially started 4604 much more tightly
>> > coupled with core, and one which backwards-compatibly worked with the
>> > current user-based messaging system. Malcolm specifically requested
>> > that this should be written as a stand-alone contrib app rather than
>> > part of core, and that it should have minimal impact on existing code.
>> Sorry - perhaps I need to be more clear on my intent here. I'm
>> convinced of the importance of session-based messages - just not of
>> when and how a particular implementation should be added to trunk.
> Thanks for your clarifications.
>> What I'm talking about is an orthogonal set of modifications that
>> would allow for _any_ messaging system (database backed, session
>> backed, or magic pony backed) to be used. This doesn't couple a
>> particular implementation of session-based messages to the core, but
>> it would allow for end-users to choose a session-based message
>> framework if they found one that was appropriate to their needs. In
>> the fullness of time, we may end up adding django-notify or similar to
>> contrib, but if we add the plugable backend we can defer that decision
>> until much later when implementations have stabilized and a clear
>> implementation winner has emerged.
> django-notify is built on a pluggable backend architecture.
> It comes with packaged with three backends, and custom backends are
> also supported.
>> As it stands, I'm aware of at _least_ two
>> implementations (django-notify and djangoflash),
> I agree, the decision is important to get right.
> To clarify, django flash is actually more than just a session
> notification backend, it introduces a whole new temporary (but cross-
> request) variable scope.
> Leah has a messaging implementation which uses django-flash:
> http://github.com/leah/django-flash-status
> So the question changes into, "are we after just a notification system
> or do we want to have a more open (but arbitrary) system of a
> temporary cross-request variable scope?"
Forgive me, but isn't a "temporary cross-request variable scope" just
sessions or cookies?
Alex
-- "I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
On Sun, Sep 20, 2009 at 6:13 PM, Chris Beaven <smileych...@gmail.com> wrote: > Having some kind of defacto cross-request notification system makes > sense; it's a very common usage pattern. > Attaching these kind of messages to a User instance is wrong: there is > not an enforced one to one correlation between a user and a session > [1], and you can't notify anonymous sessions.
Exactly. What makes this such a pressing issue for me is that the current user.message_set implementation directly *encourages* the (bad) habit of attaching messages to a user, without offering a more extensible alternative. There are many situations in which the message_set implementation breaks down and reasons why a more robust standard is needed, and needs to be blessed by the core developers. To mention a few:
1) it's not possible to create messages for anonymous users 2) if the same Django user is logged in twice on different computers simultaneously, they see each others' messages 3) as Chris mentioned, messages may get wiped even if they're not actually displayed to the user 4) high-load sites want to avoid the unneeded database or cache usage 5) since the built-in implementation is broken and no standard exists, reusable apps don't know what system to use and hence cannot rely on providing session feedback 6) it's debatably a more common problem than anything else in contrib: A site that doesn't allow users to login (hence no contrib.auth) may still need session-specific feedback.
Implementation-wise, it's also a very simple problem. Sessions and cookies will cover 95% of the use cases at hand. Both are necessary for a couple reasons: cookies may not be large enough to store all messages, and the session may be more expensive to use (and hence should be avoided if possible). For the remaining 5%, it's incredibly easy to write a custom backend in at least one of the messaging/notification options out there.
In my mind what we need now is more eyes on the code and more feedback about the pros and cons of each option out there. Perhaps something as simple as a wiki-based table would do. I've previously summed up the criteria for what I think would make a solid notification engine and only found one app that did it, but that may have changed and there are probably options out there that I don't know about. My post and the feedback I received can be found here:
On a side note, I talked with Simon about this at the sprints and he made the point that we also need a genuine, cryptography expert-approved cookie-signing utility in the core, which this messaging/notification app would ideally use. The issue, as I understand it, is that we want to be certain pickling misc. objects and sticking them in a cookie is actually secure, and not rely on (with all due respect) [some random cookie signing implementation].
> You also mention that there are a number of other implementations, but > you haven't really given a compelling survey or analysis of the > alternatives - you've just blessed one in particular. Why?
How about same session (or same cookie sent by browser) with
simultaneously opened windows of one browser? Then message could
appear in different window not the right one where we invoke the
event. Is it a problem? Is only possibility to get of this issue that
flash app should add a query parameter into redirected url which would
identify the right window?
Vaclav
On Sep 22, 3:08 am, Tobias McNulty <tob...@caktusgroup.com> wrote:
> > You also mention that there are a number of other implementations, but
> > you haven't really given a compelling survey or analysis of the
> > alternatives - you've just blessed one in particular. Why?
Vaclav,
I think this is less of an issue, because you'd have to switch to another
tab and perform a second operation that generated feedback in the ~200
millisecond window of time between clicking a link and the new page loading.
If you need to support this functionality, you could write a storage to put
the message directly in the URL query string, either by adding it to the
request Location header for HttpResponseRedirect objects or by parsing the
response output and sticking in the extra parameter for all URLs on the
page, but this is obviously pretty ugly and in my mind not worth the effort.
On Tue, Sep 22, 2009 at 11:17 AM, veena <vsto...@gmail.com> wrote:
> Hi Tobias,
> good idea with start a wiki page.
> I'm not sure if we don't forget one issue.
> How about same session (or same cookie sent by browser) with
> simultaneously opened windows of one browser? Then message could
> appear in different window not the right one where we invoke the
> event. Is it a problem? Is only possibility to get of this issue that
> flash app should add a query parameter into redirected url which would
> identify the right window?
> Vaclav
> On Sep 22, 3:08 am, Tobias McNulty <tob...@caktusgroup.com> wrote:
> > On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
> > > You also mention that there are a number of other implementations, but
> > > you haven't really given a compelling survey or analysis of the
> > > alternatives - you've just blessed one in particular. Why?
On Wed, Sep 23, 2009 at 1:55 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > Vaclav, > I think this is less of an issue, because you'd have to switch to another > tab and perform a second operation that generated feedback in the ~200 > millisecond window of time between clicking a link and the new page loading.
Ah... the wonderful American perspective of the internet. :-)
As a proud resident of the antipodes, allow me to assure you that 200ms is not a representative sample of the time required to load a page for those of us that don't live in the continental USA.
Let's consider Rackspace as a representative sample of a US based server with plenty of bandwidth. As the crow flies, I'm about 17000 km from a server in Texas. By simple laws of physics, it takes 60ms for the signal to get from me to the server, and 60ms for the signal to get back. That's 120ms, and I'm not even taking into account:
* The time spent going through the 14 routing points between me and Rackspace's servers
* The fact that the cable between me and Texas doesn't follow the same route as a crow
In reality, I get a ping time closer to 300 ms. And that's to a high-end data center under ideal conditions - it can be much larger if I'm dealing with low end providers.
Now add the time required to actually compute a response.
To put this in practical perspective - during DjangoCon, I heard lots of people complaining about the speed of the hotel wireless network. I didn't notice a serious change from what I use at home every single day.
In this particular case, I think you're correct - I'm not especially concerned about parallel cookie requests. However, there are plenty of arguments that get made on the assumption that the internet is a form of instant communication (<cough> database connection lag </cough>). I want to drive home the point that Earth is a very large place, and no matter where you are located, most of the world's population isn't anywhere near you - and no amount of technology will fix problems caused by the laws of physics.
On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee <freakboy3...@gmail.com
> wrote: > In reality, I get a ping time closer to 300 ms. And that's to a > high-end data center under ideal conditions - it can be much larger if > I'm dealing with low end providers.
What?? 200 ms is the average quoted by Mr. Sproutcore himself!
No, in all seriousness, my apologies for making such a broad generalization about packet latency. I could/should have said 500 ms or even a second; the argument and corresponding solution, if needed, remain the same.
Anyways..we digress. I am marking this a non-issue in my own head - please pipe up if there's a case to be made.
I'm a bit late in here, and it seems we reinvented a wheel as well
(even tho we did this about a year ago), but recently just OS'd our
simply notices system [1]. I'm also +1 for including something like
this in trunk rather than using the current user messages. I had a
brief look at django_notify and its a similar approach, but it seems
much more configurable than what we wrote.
> On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee <freakboy3...@gmail.com
> > wrote:
> > In reality, I get a ping time closer to 300 ms. And that's to a
> > high-end data center under ideal conditions - it can be much larger if
> > I'm dealing with low end providers.
> What?? 200 ms is the average quoted by Mr. Sproutcore himself!
> No, in all seriousness, my apologies for making such a broad generalization
> about packet latency. I could/should have said 500 ms or even a second; the
> argument and corresponding solution, if needed, remain the same.
> Anyways..we digress. I am marking this a non-issue in my own head - please
> pipe up if there's a case to be made.
In hopes of jump starting this conversation once again, I made some significant changes to the wiki page that try to sum up the state of the conversation so far in a better way:
* Coming to consensus on a de facto standard API suitable for inclusion in Django
I originally put it on the TODO list, but in retrospect the discussion needn't wait till we pick a solution.
As a practical starting point, I copied the API for django-notify to the wiki page. I like the general form of that API, but I'd be slightly more happy with something like:
from django.contrib import messages
request.messages.add('message', messages.INFO) # or request.messages.add('message', classes=(messages.WARNING,)) # or request.messages.error('message')
A la python logging, I think endorsing a specific set of message classes or tags (but still allowing them to be extended) is A Good Thing because it helps reusable apps provide more customized feedback in a standard way.
> * Coming to consensus on a de facto standard API suitable for
> inclusion in Django
> I originally put it on the TODO list, but in retrospect the discussion
> needn't wait till we pick a solution.
> As a practical starting point, I copied the API for django-notify to
> the wiki page. I like the general form of that API, but I'd be
> slightly more happy with something like:
> from django.contrib import messages
> request.messages.add('message', messages.INFO)
> # or
> request.messages.add('message', classes=(messages.WARNING,))
> # or
> request.messages.error('message')
> A la python logging, I think endorsing a specific set of message
> classes or tags (but still allowing them to be extended) is A Good
> Thing because it helps reusable apps provide more customized feedback
> in a standard way.
On Sat, Oct 10, 2009 at 19:53, Tobias McNulty <tob...@caktusgroup.com> wrote: > I should have also added:
> * Coming to consensus on a de facto standard API suitable for > inclusion in Django
The suggested API: how hard will it be to use different message-types in addition to the syslog-like ones? I use django-notify now and the types I use is nothing (for info), "error", and "help" (for help/tips). I've also made django-notify optional in my reusables, with a dummy-object if it is not installed. Locking them down with class.attributes will find typos of course, but right now I don't have to import anything just to use session-messages, I just do a hasattr(request, 'notifications') .
On Sat, Oct 10, 2009 at 6:44 PM, Hanne Moa <hanne....@gmail.com> wrote: > The suggested API: how hard will it be to use different message-types > in addition to the syslog-like ones?
I think it should definitely be easy, if not actively encouraged. IMO those constants should just be strings, or integers which can easily be mapped to strings (like in Python logging). This would give you the flexibility of passing in anything you want. django-notices does it the latter way:
Today I was on very bad wifi connection. Constantly dropped. 20
seconds to load a page.
I save in admin in two tabs and got a notice in one tab from the other
tab.
But I agree, I defer this "bug" for the first release od django
messaging. I think django isn't now in right mood to add there some
functionality like adding of query parameters to response object by
some application. Maybe in future.
Vaclav
On Sep 23, 4:49 am, Tobias McNulty <tob...@caktusgroup.com> wrote:
> On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee <freakboy3...@gmail.com
> > wrote:
> > In reality, I get a ping time closer to 300 ms. And that's to a
> > high-end data center under ideal conditions - it can be much larger if
> > I'm dealing with low end providers.
> What?? 200 ms is the average quoted by Mr. Sproutcore himself!
> No, in all seriousness, my apologies for making such a broad generalization
> about packet latency. I could/should have said 500 ms or even a second; the
> argument and corresponding solution, if needed, remain the same.
> Anyways..we digress. I am marking this a non-issue in my own head - please
> pipe up if there's a case to be made.
On Sat, Oct 10, 2009 at 7:03 PM, veena <vsto...@gmail.com> wrote: > Today I was on very bad wifi connection. Constantly dropped. 20 > seconds to load a page. > I save in admin in two tabs and got a notice in one tab from the other > tab.
> But I agree, I defer this "bug" for the first release od django > messaging. I think django isn't now in right mood to add there some > functionality like adding of query parameters to response object by > some application. Maybe in future.
AFAIK this will become a non-issue with the advent of HTML5, as each window/tab will have its own session.
I also don't think this problem is being addressed here. Yes you could
pass messages to the context, but you would lose the ability to
retrieve those variably. I believe storing it in the existing session
is the best appoach for django's builtin support.
Sent from my iPhone
On Oct 10, 2009, at 8:00 PM, Tobias McNulty <tob...@caktusgroup.com>
wrote:
> On Sat, Oct 10, 2009 at 7:03 PM, veena <vsto...@gmail.com> wrote:
>> Today I was on very bad wifi connection. Constantly dropped. 20
>> seconds to load a page.
>> I save in admin in two tabs and got a notice in one tab from the
>> other
>> tab.
>> But I agree, I defer this "bug" for the first release od django
>> messaging. I think django isn't now in right mood to add there some
>> functionality like adding of query parameters to response object by
>> some application. Maybe in future.
> AFAIK this will become a non-issue with the advent of HTML5, as each
> window/tab will have its own session.
On Mon, Oct 12, 2009 at 10:21 AM, David Cramer <dcra...@gmail.com> wrote: > I also don't think this problem is being addressed here. Yes you could > pass messages to the context, but you would lose the ability to > retrieve those variably. I believe storing it in the existing session > is the best appoach for django's builtin support.
I'm not exactly sure what problem you see as not being addressed, and I don't think you were arguing against this, but it has been noted elsewhere that it's more desirable to store the messages directly in a cookie, if possible, to avoid the extra database or cache hit.
It seems well worth it to me and there are solutions out there that try to store the messages in a cookie and then fall back to the session for longer (>4kb) messages.
On Sat, Oct 10, 2009 at 2:05 PM, David Cramer <dcra...@gmail.com> wrote: > The proposal per your email is more or less how django-notices works.
For me, the best solution would be a combination of django-notify and django-notices. django-notify for their fallback backend and the interchangeable backend support in general, and django-notices for the logger-like API. I especially like the NOTICE_LEVEL setting which could easily be controlled via your DEBUG setting. I agree that custom levels should be easy and encouraged, and the strings used even for the built-in levels should be configurable.
