Session/cookie based messages (#4604)

[Tobias-41]

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?

Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[hanne]

On Fri, Sep 11, 2009 at 01:00, Tobias <tobias.mcnulty@...> 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:

http://example.com/?msg=Shiver+me+timbers

Whether being able to do that at all is desirable is another question
entirely ;)

Big bonus in my view: it's completely independent of the
django.contrib.auth-system.

> What needs to be done to get this or something like it into contrib?

Yes, this inquiring mind also wants to know.


HM

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Fri, Sep 11, 2009 at 7:00 AM, Tobias <tobias.mcnulty@...> 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.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[SmileyChris]

> 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.
--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileychris@...> 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.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[SmileyChris]

On Sep 21, 12:05 pm, Russell Keith-Magee <freakboy3...@...>
wrote:

> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@...> 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?"
--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

On Sun, Sep 20, 2009 at 11:30 PM, Chris Beaven <smileychris@...> wrote:

>
>
>
> On Sep 21, 12:05 pm, Russell Keith-Magee <freakboy3...@...>
> wrote:
>> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@...> 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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sun, Sep 20, 2009 at 6:13 PM, Chris Beaven <smileychris@...> 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:

http://www.caktusgroup.com/blog/2009/06/19/towards-a-standard-for-django-session-messages/

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].

Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <freakboy3742@...> 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?

I started a wiki page comparing some of the different options out there:

http://code.djangoproject.com/wiki/SessionMessages

Feel free to update with (your messaging backend here).

Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[veena-7]

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...@...> wrote:

> On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
>
> freakboy3...@...> 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?
>
> I started a wiki page comparing some of the different options out there:http://code.djangoproject.com/wiki/SessionMessages
>
> Feel free to update with (your messaging backend here).
>
> Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

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.

Tobias

On Tue, Sep 22, 2009 at 11:17 AM, veena <vstoupa@...> 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...@...> wrote:
> On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
>

> freakboy3...@...> 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?
>
> I started a wiki page comparing some of the different options out there:http://code.djangoproject.com/wiki/SessionMessages
>
> Feel free to update with (your messaging backend here).
>
> Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Wed, Sep 23, 2009 at 1:55 AM, Tobias McNulty <tobias@...> 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.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee <freakboy3742@...> 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.

Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[David Cramer-2]

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.

[1] http://github.com/dcramer/django-notices

On Sep 22, 9:49 pm, Tobias McNulty <tob...@...> wrote:

> On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee <freakboy3...@...
>
> > 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.
>
> Tobias

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

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:

http://code.djangoproject.com/wiki/SessionMessages

Things that still need to be discussed/done:

* Coming to consensus on what 3rd party app we actually choose to
extend/modify to fit into Django

* What to do with the existing user message API (see
http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI)

* Review/add to the TODO list on the wiki
(http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen)

Cheers,
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty <tobias@...> wrote:

> Things that still need to be discussed/done:
>
> * Coming to consensus on what 3rd party app we actually choose to
> extend/modify to fit into Django
>
> * What to do with the existing user message API (see
> http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI)
>
> * Review/add to the TODO list on the wiki
> (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen)

I should have also added:

* 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.

Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[David Cramer-2]

The proposal per your email is more or less how django-notices works.

Sent from my iPhone

On Oct 10, 2009, at 12:53 PM, Tobias McNulty <tobias@...>
wrote:

>
> On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty <tobias@...
> > wrote:
>> Things that still need to be discussed/done:
>>
>> * Coming to consensus on what 3rd party app we actually choose to
>> extend/modify to fit into Django
>>
>> * What to do with the existing user message API (see
>> http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI
>> )
>>
>> * Review/add to the TODO list on the wiki
>> (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen
>> )
>
> I should have also added:
>
> * 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.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> [phone]
> http://www.caktusgroup.com
>
> >

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sat, Oct 10, 2009 at 2:05 PM, David Cramer <dcramer@...> wrote:
> The proposal per your email is more or less how django-notices works.

For comparison I added django-notices to the Available Options:

http://code.djangoproject.com/wiki/SessionMessages#AvailableOptions

--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[hanne]

On Sat, Oct 10, 2009 at 19:53, Tobias McNulty <tobias@...> 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') .


HM

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sat, Oct 10, 2009 at 6:44 PM, Hanne Moa <hanne.moa@...> 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:

http://github.com/dcramer/django-notices/blob/master/django_notices/constants.py

I clarified that criterion in the wiki:

http://code.djangoproject.com/wiki/SessionMessages#Criteria
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---