Date: 10/13/00
- Next message: Kristian Köhntopp: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Previous message: rick <email protected>: "[PHP-DEV] PHP 4.0 Bug #7175: "perdir" ini settings are not per dir"
- In reply to: Zak Greant: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Next in thread: Ulf Wendel: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Zak Greant wrote:
> Personally, I have no idea - it is a term that seems to be
> applied differently by everyone. It seems like the whole
> OO buzz of a few years ago - everything had an OO-based
> architecture... in the end, it all meant very little.
Actually, the term is pretty good defined, at least with
respect to the problems one is trying to solve.
An application is a program (code) plus state (data). In web
applications, there is always the problem of keeping state, that
is having per-browser data and making this data immortal (longer
lived than a single request). PHP4 partially solves this problem,
as it addresses the per-browser data part by defining sessions
and propagating these in different ways (cookies, and GET-variables).
It also addresses the problem of immortal variables, but in a
kludgy way, as session variables in PHP are not immortal, but
resurrected on the next page.
This is okay for simple variables, but becomes a problem when you
want to serialize references (remember that discussion here on
this list?) and when you want to keep variables which are only
handles to arbitrary structures of data outside of PHP (we call
them ressources in PHP).
The answer to these problems is to keep them around, instead
of letting them die at the end of a request. If you want to
do this without interfering with the process model of each and
every web server you are going to support, you need a coprocess to
the web server and this process is allocating ressources and
keeping application state variables. Basically, you remove PHP
from the web server and put it into a process of its own, a
coprocess to the web server.
In order to serve requests efficiently, you need multiple control
flows, each of which can execute requests on its own. In order
for these control flows to share data and ressources easily, they
should be in the same process space (you cannot pass file handles
via shared memory, can you?). That is, your coprocess should be
multithreaded.
> IMHO PHP easily qualifies as an application server - but so
> would almost any of the web scripting languages...
No, as an application server is not part of the web server, and
is able to keep all kind of state independently from requests.
PHP4 is currently limited with respect to this, and only the
coprocess construct will ultimately help to remove these
restrictions.
Kristian
-- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: Kristian Köhntopp: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Previous message: rick <email protected>: "[PHP-DEV] PHP 4.0 Bug #7175: "perdir" ini settings are not per dir"
- In reply to: Zak Greant: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Next in thread: Ulf Wendel: "Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

