On Fri, Jul 30, 2010 at 7:16 AM, Vito <vitorre...@gmail.com> wrote: > > > On 29 jul, 17:39, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: >> Hi Vito -- >> .... >> Jacob > > > Mr Jacob Kaplan-Moss, I am very happy to receive a response from you. > It is a very valuable information. > > I just like to say something, to you and the rest of Django > developers: > > Django is a framework made by perfectionists for perfectionists, but > it is not good that they are as conservative. I guess it's not an easy > job to have a framework so robust and yet so modern that supports the > latest technology. > > I have to go a long way to keep up with the developers of Django, but > soon I will be and try to help in the project from now. > > I think every time a new technology comes out you should start a > conversation to begin to discuss how it will be integrated into > Django, so that, sooner rather than later, Django supports the latest > technology: not only database, also client side technologies, web 2.0, > security. etc.
Hi Vito, Thanks for the suggestion. However, I would like to make a couple of comments in defence of our "conservative" approach. Firstly, the Django core team (and, for that matter, everyone else working on Django) is a volunteer group. We have limited time and resources, so we can't spend all our time discussing what might be or could be. If we did this, we would spend all our time discussing, and no time actually *doing*. The good news is that we don't need to have a single coordinated centralized discussion in order to make progress. Since Django is an open source project, anyone can contribute. If you think that an emerging technology is important, you have the source code, so you can try to implement an interface to that technology. If your change requires modifications to Django's core, you can propose those changes. Rather than have a start the process with a speculative "should we implement" or "how could we implement" discussion, we prefer to let the community establish what is possible, and let the community make a concrete proposal based on practical experience. For example, there has been lots of interest recently in NoSQL data stores. As a result, several groups have gone off and built NoSQL interfaces that can be used in Django. Some of these are unrelated to Django. Some of these leverage parts of Django, but work without any modifications to core. Some are effectively a speculative fork of Django. However, as a result of these independent projects, we're now in a position to be able to recommend a good path forward for the core -- and that's what Alex is implementing in the Summer of Code. Secondly, Django has a very strong policy of backwards compatibility. Once we introduce an API, we guarantee not to change it. That means we need to be *slightly* conservative when we adopt. We don't want to introduce an API for NoSQL in version 1.3, only to completely change the interface in version 1.4. We also don't want to end up having to support dozens of bad interfaces to emerging technologies that never really get beyond the initial buzz phase of their lifecycle. Thirdly, it's also important to note that just because a technology is important, it doesn't mean it needs to be part of Django. For example, you mentioned client-side technologies. Django is a server-side framework. Why does Django need to evolve client-side features? Why can't those feature emerge as a separate project? On the other end of the stack, Django doesn't need to evolve into a web server, either. We'd rather Django be a small project surrounded by a vibrant community of other small projects, rather than try and evolve Django into a massive "do-everything" framework. Lastly, its important to note that just because Django doesn't have a baked-in solution for <insert hot new feature here> doesn't mean it can't be done in a Django stack. As Jacob pointed out, there are already several ways to do NoSQL in a Django project. So -- if you think there is some emerging technology that Django should support, the first step is to try to implement your idea independent of Django itself. Try and work out if it can be a standalone project, or a library that 'plugs in' to existing Django interfaces. If it turns out that means changes are required in Django to support your new idea, feel free to make a suggestion, explaining why those changes are required. We're always open to suggestions -- but we're even more open to people in the community making the wider Django ecosystem a richer and more vibrant place to live. 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-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=en.
