[Web-SIG] windows, pywebd, webctl

Chad Whitacre chad at zetaweb.com
Thu Mar 8 05:55:37 CET 2007



Sidnei, et al.: your points are well-taken and your expertise 
appreciated. Thanks!


Bob: I'm on board with your vision for a common server library 
here. Count me in.

webctl/filesystem layout/config syntax

This is looking less hopeful as a place to collaborate:

   - An executable needs a config file on the command line, and/or
     a config file in a pre-determined place.

   - *Requiring* a config file on the command line is butt-ugly.

   - Our opinions regarding filesystem layout seem to be, um,

I'd like to venture one more round on this, however, before 
giving up on it:

   - It might be the case that Zope only has a few files in an
     INSTANCE_HOME, but I find myself putting quite a bit in a
     site's userland:

       - I'll install Python packages in there wholesale, so I get
         their scripts in bin/, and lots of modules in lib/python.

       - I have multiple configuration files in etc/ (as
         discussed) along with templates in etc/templates/.

       - I put documentation in doc/.

       - I have site-specific utility or cron scripts in bin/.

       - I have extra data files in var/.

     Keeping it all in svn means that a website is very nearly
     self-contained and isolated, requiring not much besides
     Python to be installed in the base system. This is great for

   - For one-site-on-many-servers, why does a Unix-y userland for
     development conflict with deployment? That is, why can't a
     development userland simply be installed into /usr/local for
     deployment? Surely logging differences could be handled in
     configuration, no?

   - Besides, my proposal only specified two requirements:


     Is there really a Unix sysadmin that would balk at this? This
     is all that's really needed for a common executable to get
     your site online. Lay out the rest however you want.

   - Jim, you hold particular distain for lib/python, but it's
     probably the best example of my "standards enable tools to
     evolve" argument: lib/python buys you distutils, setuptools,
     easy_install, workingenv, etc.

   - This same principle makes sense of runzope, scriptzope, and
     debugzope: standardize the file format (= fs layout), and
     such tools fit perfectly in /usr/local/bin.

   - Almost all of the Windows discussion has centered on daemons
     vs. services. Sidnei, et al.: what does a "native" Windows
     filesystem layout look like for a web application? Is using a
     self-contained Unix-inspired layout faux pas?

   - As mentioned wrt PHP, users like familiar filesystem layouts.
     Reaching agreement here improves our story for newcomers.

A common executable (= common fs layout) may very well be pushing 
the limits of collaboration too far, but I'll feel better about 
admitting that if we pursue the conversation a bit further.


More information about the Web-SIG mailing list