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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
