The scope is somewhat different, but the goals similar: <a href="http://cloudsilverlining.org">http://cloudsilverlining.org</a><br><br><br><div class="gmail_quote">On Tue, Oct 5, 2010 at 3:52 PM, Randall <span dir="ltr"><<a href="mailto:berryman77@gmail.com">berryman77@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The rise of WSGI and the many server implementations is really great.<br>
I've configured some combinations of webservers and WSGI servers that<br>
are very fast and reliable. Now that there's a good standard for<br>
Python web applications to build on, there is an opportunity to create<br>
a standard for very easy deployment and administration.<br>
<br>
Consider the common scenario where an administrator is responsible for<br>
half a dozen or more applications, each for a different department<br>
within a company. Instead of having each application configure its<br>
own settings for mail servers, database connections and the<br>
administrator needing to configure and install various CherrPy,<br>
Pylons, Turbogears, etc WSGI files and dependencies, it would be nice<br>
if each application, regardless of framework, could be deployed as a<br>
single file archive. The SMTP and database settings could be<br>
configured once for all applications and even application specific<br>
configuration could be configured by the administrator using a single<br>
interface. In addition, it would provide statistics about the<br>
applications and allow them to be restarted individually, again from a<br>
uniform interface.<br>
<br>
It would provide services that the applications could access through a<br>
standard interface. Mail, database, temporary files, persistent<br>
storage location. etc. It should work with any WSGI application, but<br>
an application could opt to take advantage of the services offered.<br>
<br>
An application server like this could do wonders for getting Python<br>
applications into the typical enterprise (I hate to that word, but<br>
it's very appropriate here). And yes, if my description sounds like<br>
Tomcat, that's what I had in mind. It would of course interface with<br>
a web server and probably have its own HTTP server, but you'd only<br>
have to go through that setup once instead of once per application.<br>
<br>
What it means in the end is that after this hypothetical application<br>
server is set up, a new application can be deployed by uploading a<br>
single file archive. For a single application deployment, it's not so<br>
useful, but when deploying and managing multiple applications, it<br>
could be a godsend to administrators and as a result to developers<br>
that work with them. And best of all, it could break down barriers to<br>
getting Python web applications into enterprise environments.<br>
<br>
I haven't come across any current efforts to develop something like<br>
this and I'm finishing something else at the moment. So I wrote this<br>
post to document my thoughts, see if there is any interest and<br>
possibly get a discussion going.<br>
<font color="#888888"><br>
-Randall<br>
_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com" target="_blank">http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>