Just wanted to add that the decision need not go either way; one possible solution would be to leave it up to the implementation and live with both conventions in the core.
Sent from a mobile phone, please excuse any typos. On Dec 7, 2009 7:17 AM, "Russell Keith-Magee" <[email protected]> wrote: Hi all (and especially Jacob), So - this is a call for any interested parties to express their opinions, followed (hopefully quickly) by a BDFL judgement. For those that haven't been following the the django-dev discussion around ticket #4604: session-based messages are nearing trunk ready status. After a few rounds of review, the implementation looks good, and the documentation is good. However, there is one sticking point left, and it's almost entirely cosmetic: how should we be referring to the configurable messaging backend in settings? The current code points explicitly at the class that implements the messaging interface: MESSAGE_STORAGE = 'django.contrib.messages.storage.user_messages.LegacyFallbackStorage. In a review note, I commented that there is an alternate trend in Django's source tree - that is to use the module as the configuration point: MESSAGE_STORAGE = 'django.contrib.messages.storage.user_messages' It is then assumed that the module provides a standard interface - e.g., a backend must provide a class called "StorageEngine". I suggested that the latter form (module-based configuration) was the emerging trend in Django backends, as it is followed by core.cache, core.db, contrib.session, and core.email, and the messaging backend should comply to that trend. Luke has contested the assertion that this is an emerging trend, and has expressed a preference for class-based configuration. The arguments both ways are covered in the recent messages on the #4604 threads (pointer into the discussion here [1]; the issue in question starts here [2]). [1] http://groups.google.com/group/django-developers/browse_thread/thread/eba93088c649022b/7b78cc341132061f [2] http://groups.google.com/group/django-developers/msg/952b97d82b126075 Here's my attempt at summarizing the arguments each way: Class-based configuration: -------------------------- * You can put multiple backends in one file if you want to, and you are not forced to duplicate imports or get creative with module names if you happen to have several backends that really belong in the same module. * It doesn't rely on a convention of a class with a certain name. If the user sees the setting for MESSAGE_STORAGE pointing to a class, they will immediately know where the implementation is, whereas if it points to a module and the module contains multiple classes, they will have to guess which class is the main one, or browse docs/source code. * It makes it less verbose and confusing if one backend refers to another (as happens with messages), because all the classes have different names, rather than having the same name. * It allows the user to structure their backend code however they want, unlike module-based configuration which is opinionated about code structure in a way that isn't obviously good to all observers. * The approach is consistent with file backends, template loaders, plus the specification of context processors, middleware, test runners, and the CSRF error view. Module-based configuration: --------------------------- * The aesthetic of user-configuration options is cleaner because configuration items are shorter and don't require duplication of terms. e.g., django.core.cache.backends.locmem.LocMemCacheBackend duplicates the 'locmem' bit for no real end-user gain unless you're planning to have a non-locmem backend in the locmem package. * The 'multiple backends in a single module' argument is arguably a false economy, as we should be encouraging code be modular, especially at the level of something like a backend which is by definition a concern that can be separated (after all, as Tim Peters said: Namespaces are one honking great idea -- lets do more of those). * Most end users aren't going to be writing message/cache etc backends, and if they are, they are hopefully talented enough to read documentation to find the convention, or at the very least, spot an obvious pattern in code. * Module based-backends allows for backends to be more than a single class - e.g.,the database backend, which is actually several classes. This also highlights the fact that backends are often more than just a single class - they are a package of data structures, support utilities, etc. A backend is a group of capabilities, not just a single class. * It's the approach used by db, cache, session, and email backends. * Context processors, middleware, test runners and the CSRF error view are by definition single classes or views, not really plugable backends. I hope I've done a reasonable job of summarizing the two positions in an unbiased way. This isn't just an argument about #4604, though. This issue also has a wider impact on the 1.2 release. The 1.2 release has already added email backends; messaging backends are on the way; and there is the opportunity to normalized template loaders too as a result of #6262. Backwards compatibility means that there are some old interfaces and configuration conventions that we can't change, but I think we should try to be consistent going forward. There are reasonable arguments on both sides. My personal preference is still for module-based configuration, but I won't lose sleep if it goes the other way. So, I'd like to call for a quick BDFL judgement. Everyone else should feel free to weigh in with opinions if they have opinions, preferences, or especially compelling arguments either way. 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 [email protected]. To unsubscribe from this group, send email to [email protected]<django-developers%[email protected]> . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
