<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [Web-SIG] more comments on Paste Deploy</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Jim Fulton wrote:<BR>
&gt; I believe, we're evaluating Paste Deploy at 2 levels:<BR>
&gt; 1. Can we agree on a standard set of entry points so<BR>
&gt; that WSGI applications can be combined automatically?<BR>
&gt; I think Paste Deploy provides at least good start on this.<BR>
<BR>
Yes, I think we can. And the ones in paste deploy are a good start (and end, for all I know). But if Ian's going to split Paste Deploy out into its own project (as he hinted), we should find a new namespace for them besides 'paste.*' soon.<BR>
<BR>
&gt; 2. Do we want to reuse it's configuration syntax.<BR>
&gt; On the subject of configuration format, I suppose this<BR>
&gt; is a matter of taste.&nbsp; I strongly prefer having fewer<BR>
&gt; configuration files, preferably one.<BR>
<BR>
In my head, we share a 'site daemon' among us, and a common 'webctl' front end to that daemon should use a single INI-style config file (but like Chad, I'm not sold on Paste's existing format). However, we should build the site daemon in such a way that each framework can drive it in framework-specific way, and if they wanted to layer their own config style on top of that interface, fine. This would make it easier for the various framework authors and users to explore tutorials, run tests, and deploy single-framework sites.<BR>
<BR>
In short, I'm pushing for:<BR>
<BR>
&nbsp; read conf -&gt; apply conf -&gt; del conf -&gt; work with objects<BR>
<BR>
as opposed to the much more tightly-coupled and hard-to-use:<BR>
<BR>
&nbsp; read conf -&gt; work with a mix of conf and objects forever<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>

</BODY>
</HTML>