On Sun, Aug 24, 2008 at 12:47 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: >> The plan is to use the system found in Chapter 20 of the Django book: >> >> http://www.djangobook.com/en/1.0/chapter20/ >> >> See figure 20-4 >> >> All the Django app servers will be running mod_wsgi and will be placed >> behind a server running perlbal or Apache with mod_proxy. Looking at >> our current setup, the main reason we use daemon mode is because we >> needed file ownerships and permissions for uploaded files to be >> handled correctly. > > The problem there being that Django folks recommend mod_python. ;-)
Heheh. We threw out mod_python two years ago and never looked back. Besides, all you need to do is just s/mod_python/mod_wsgi/ while reading those docs ;-) > It is interesting to see in mod_wsgi site statistics that Django page > is finally starting to overtake Trac page as most popular page for > third party application. Rather telling though is that whereas there > are lots of referrals from Trac site in its documentation to mod_wsgi > site, there are hardly any coming from Django site. It just doesn't > get much mention on Django site. > > Rather amusing is the conversations that go on on #django irc pitting > mod_wsgi against mod_python. Not amusing is the lack of knowledge many > of the people there appear to have about mod_wsgi and thus the > information they give about mod_wsgi is rather thin, incomplete and > sometimes inaccurate. Thus, although they may be recommending > mod_wsgi, I fear that people when they go use it will not get the > experience the others have been promising. It would be okay if people > then went and read the documentation on mod_wsgi site to learn about > it, but many seem not to as they often turn around and complain about > the lack of documentation on mod_wsgi and how there is so much more > documentation about mod_python. > > Sometimes one just has to shake your head and wonder why you bother. :-( Well, I blame ADHD and "Web 2.0" :-) I think the problem here is that a lot of these folks just want something that they can get "up and running quickly". I don't know how they can complain about "lack of documentation" when there are reams and reams of it on the Wiki! Maybe it's because the Google Code Wiki is just butt ugly ;-) This is why it took me over 6 months to finally switch from mod_python to mod_wsgi. Too much stuff to read. Prior migration I had to basically skim through the entire "Basic configuration guide for mod_wsgi". Printing it out on US Letter size paper, that's 11 pages worth of documentation. I skimmed through it because for doing something "basic" I was expecting a short working example, followed by an explanation of what is going on in the configuration. In short, "basic configuration" should have only contained all the "basics" you need to get a working config. When I finally got a "basic" working config running, I had to dig through even more documentation to find the correct way of setting up a working config for a Django-based app. After I had that running I had to look up how to set up daemon mode. Between staring at a wall of text and actually getting our final config done, I had to re-evaluate if all of this reading is really necessary (fortunately the answer is yes!). IMHO, I think the docs need to be restructured/reorganized to cater to those who either have ADHD or simply have not enough time to sit through reading a lengthy manual. For instance, it would be useful to present working, commented configuration examples for frequent use cases all within the context of a VirtualHost container: * Basic configuration - contains only the directives you need to get up and running. * Basic daemon mode configuration - contains only the directives you need to get up and running. * Daemon mode process delegation - how to delegate certain URLs to separate daemons, file uploads as an example. This will illustrate that it is possible to have multiple WSGDaemonProcess directives in one VirtualHost. * Examples for the popular Python frameworks like Django, Pylons, TurboGears, Zope, etc. * Examples for Authentication. etc. Even better, provide a downloadable tarball of these sample configuration files or even include them in the mod_wsgi tarball itself. This would give the "up and running quickly" folks something that they can use as a template and modify to their needs without having to bother to read the manual (which they flat out refuse to do anyway). >> All this works with LocationMatch as well yes? > > Yes. And DirectoryMatch and FilesMatch. > > In: > > > http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIProcessGroup > > you will see the 'Context' entry being 'server config, virtual host, > directory'. This tells you where in Apache configuration the directive > can be used. Follow the cross link for 'Context' and you will get > Apache definitions of what those mean. > > http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context Hmm. I think this is another reason why a lot of folks don't bother with the docs. You followed the format used by Apache :-) Alphabetical list of directives cross-linked to other directives. -- Best Regards, Nimrod A. Abing W http://arsenic.ph/ W http://preownedcar.com/ W http://preownedbike.com/ W http://abing.gotdns.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
