Hi Russell, thanks for all your feedback. I'll review the small issues in a separate email (or just fix them), but here are my responses to the two bigger problems.
On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee <freakboy3...@gmail.com > wrote: > * I think there's a circular reference problem in the middleware with > the setup for request.messages. The messages middleware actually > creates request.messages, but the auth middleware creates a lazy > evaluator that can return request.messages. This means that as a > request comes in, the request is always given a lazy evaluator for > user.messages_set, which is then overwritten by the messages > middleware. The consequence of this is that any middleware that is > executed between the auth and messages processors will get > user.message_set if they try to set a message. > The auth middleware now returns the same thing the messages middleware does, so that may change the problem a little. Still, I'm not sure what the consequence would be of using messages between the two middlewares. I'll give it some thought and propose/implement a fix if it looks problematic. > * I have some concerns about the thread-safety (or, rather, > request-safety) of the various backends. If I'm reading the code > right, if you have two parallel requests, a message written in one > response will overwrite a message written in the second, which will > result in the first message never being displayed to the user. This > wasn't a problem with the old API because messages were written to the > database on response, and read on request; the first request would get > all the messages. If we're using cookies and sessions, there's all > sorts of clobbering problems. > True. One simple solution would be to offer another "thread safe" backend that used the database as a storage (independent of the User model of course). As long as we note the lack of thread safety in the cookie and session backends I think they'll still be alright for most cases; hopefully this is something that folks using sessions and cookies are prepared to deal with. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 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-develop...@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=.
