Hi folks -- I had a conversation this morning with one of my clients. In the interests of being a good corporate citizen I'll refrain from mentioning who other than (a) they're big (Fortune 1000), (b) you've heard of them, and (c) they're using Django.
Before our chat, they'd invited any engineers internally to bitch about Django, and they shared some of the pain points they'd come across. I took some notes; the really good news is that it's a short list, and we already know about most of it. Before I share the list, I should mention that I'm not arguing we have to immediately devote resources to these problems, nor even that we have to solve them. I'm sharing this just as food for thought, and as a perspective from a class of developers who mostly don't participate in our process at all. So: The main issue they have is multiple database support. Music to my ears (and especially Alex's :) since it looks like 1.2 will solve most (all?) of their issues. My main takeaway from this point was that the best way to please companies like this one will be to ship 1.2 on time. Which will happen. So we rock. The next big one was the "startup signal" issue -- they've got lots of code that needs to run at startup time, and there's no great mechanism to do that currently. The core devs have talked about this one a *lot* over the years, and it's obviously a hard one -- for one, there's no clear definition of what "startup" means -- but a common theme seems to be that bigger, more complex applications need some way to cleanly run one-time, expensive startup tasks. Next, we discussed the difficulty of maintaining large installations with multiple sites, a plethora of apps, and unspeakable possible combinations thereof. Django's settings mechanism is simple and easy to use, but once you have hundreds of sites it starts getting really tricky to keep things in sync across hundreds of settings files. We talked at some length about different possibilities for dynamic settings infrastructure; this would especially come in handy for folks wanting to build application servers/services like App Engine or the nascent Toppcloud. <digress>If you've not yet checked out Toppcloud, do so now. I'll wait.</digress> Finally, we ruminated over the difficulties in building rich internet applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, but we doesn't really have a good answer for the people who want something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting all sorts of marketing dollars into Flex/Silverlight, and although HTML5 can do some amazing things, the lack of tooling is a big danger. (I've written at more length about this in the past: http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications). Of course, there may not be much us backend folks can do about this problem -- I'm certainly not enough of a GUI application guy to be able to even start to think about this problem -- but the lack of an end-to-end solution will nonetheless put some off from writing web applications with open source tools. So there we are. This is very much a brain dump, and I don't really expect any concrete action to result from it. However, I found some really interesting stuff there, and I thought I'd share. Jacob
-- 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.
