On 30 Jan, 21:27, walterbyrd <[EMAIL PROTECTED]> wrote:
> Thanks for all that posts. This thread has been helpful.
>
> I have seen a lot of posts about the importance of decoupling the
> deployment technologies from the framework technologies. This is how I
> have done that in PHP. I develop on my
Thanks for all that posts. This thread has been helpful.
I have seen a lot of posts about the importance of decoupling the
deployment technologies from the framework technologies. This is how I
have done that in PHP. I develop on my home box. When I get something
working the way I want, I ftp thos
On 29 Jan, 18:11, walterbyrd <[EMAIL PROTECTED]> wrote:
> I don't know much php either, but running a php app seems straight
> forward enough.
I think that this (the ease of PHP application deployment) is one of
the things that keeps Python framework developers up at night,
regardless of whether t
walterbyrd wrote:
> Python also seems to require some sort of "long running processes" I
> guess that the python interpretor has to running all of time.
What you probably don't realize, is that in 99.9% of the situations you've
come across, PHP is already a process running all the time. It's call
walterbyrd a écrit :
> I don't know much php either, but running a php app seems straight
> forward enough.
Mmm... As long as the whole system is already installed and connfigured,
*and* matches your app's expectations, kind of, yes.
> Python seems to always use some sort of development environm
On Jan 29, 2008 12:11 PM, walterbyrd <[EMAIL PROTECTED]> wrote:
> I am not really sure about what wsgi is supposed to accomplish.
This will explain WSGI: http://www.python.org/dev/peps/pep-0333/
--
http://mail.python.org/mailman/listinfo/python-list
I don't know much php either, but running a php app seems straight
forward enough.
Python seems to always use some sort of development environment vs
production environment scheme. For development, you are supposed to
run a local browser and load 127.0.0.1:5000 - or something like that.
Then to ru
