I'll respond in a high-level way. I believe, we're evaluating Paste Deploy at 2 levels:
1. Can we agree on a standard set of entry points so that WSGI applications can be combined automatically? I think Paste Deploy provides at least good start on this. 2. Do we want to reuse it's configuration syntax. You haven't commented on the entry points defined by Paste Deploy. Do you have an opinion on adopting the entry-point API defined by Paste Deploy? On the subject of configuration format, I suppose this is a matter of taste. I strongly prefer having fewer configuration files, preferably one. One of the things I like about zc.buildout is that it lets me gather my configuration in one file. The configuration format used by Paste Deploy is a simple standard format used by many many systems inside and outside the Python community. This makes it easy for people to learn and understand. Obviously, we can agree to disagree on this. I'd very much like, at a minimum, to agree on the entry point API so we can more easily collaborate on interoperable applications, middlewear, and servers. Jim On Mar 2, 2007, at 10:29 PM, Chad Whitacre wrote: > All, > > Thanks, Jim and Ian, for bringing this discussion online. > > I have two hesitations with Paste Deploy: > > 1. The configuration syntax is really complex. I'm much more > comfortable with multiple simpler config files. > > 2. I'm not clear on how Paste Deploy's abstractions map to the > filesystem. What does my website root look like? > > > With Aspen, I went with a well-defined filesystem layout (a > Unix-style userland) and multiple configuration files (in etc/), > each with their own simple syntax. > > So if you publish a blog app called SuperBlog, let's say, you > would mount it in etc/apps.conf, e.g.: > > / myapp:root > /blog superblog:main > > SuperBlog would configure itself with etc/superblog.conf, a file > with a simple syntax described in your SuperBlog documentation. > SuperBlog also has access to Aspen's global config through a > simple API. > > I suggest that a system with multiple simple config files is much > more scalable than a single complex config file syntax. Imagine > if all of Unix were configured using a single syntax! > > > Also, I don't think we should underestimate the importance of the > file/executable distinction. A standard "file format" for a > website enables a wider tool ecosystem to evolve: interactive > shells, debuggers, test runners, skel systems, configuration UIs. > It also makes any given website easier to comprehend and maintain. > > > So in short, I give Paste Deploy a -1 as our main configuration > system. I'd like the first-line config to be much simpler, with > Paste Deploy available as an optional extra. > > > > > chad > _______________________________________________ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/jim% > 40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
