[phplib] Fwd: Kristian Köhntopp's PHP app server message From: Chris Johnson (chris <email protected>)
Date: 04/18/01

-----Original Message-----
From: Kristian Köhntopp [mailto:kk <email protected>]
Sent: Thursday, January 18, 2001 6:19 AM
To: phplib <email protected>
Subject: [phplib] The change to PEAR...

I have done very little with PHPLIB in the past year, as my job
and my private projects have led me past it in some way. I have
not the time to maintain this project any longer, and I do not
believe that PHPLIB is the right frame for a PHP class library
any more. I will try to explain the why and how in the paragraphs
below.

The change to PEAR is done for the sake of continuity, not to
break it. Sebastian, Ulf and I know full well that there are plenty
of projects out there which depend on the PHPLIB APIs. We do
not want to break this code. Any import of PHPLIB code into PEAR
will be done in a way that there is a soft and easy migration
path. Also, we want to bring our expertise in library design
into PEAR in order to promote this project.

The advantage of PEAR that singles it out from all other PHP class
libraries is that it is part of a standard PHP 4 install. This does
wonders for the availability of the code in a hosted environment
and on your average Linux distribution. Also, the PEAR project
has a much larger developer base than PHPLIB currently has (basically
Ulf, and the fraction of my time I can find for it).

By becoming part of PEAR, our code will be part of such a standard
install, and this will greatly relieve installation and availability
problems for those of you with projects depending on PHPLIB. This
is a good thing, if done right - and we will do it right.

Why has the development of PHPLIB virtually stopped in the past
year, and what have I done in that time?

At the 1st Januar 2000, the german language newsgroup
de.comp.lang.php has been created based on an initiative started
by me. I have "adopted" that newsgroup for 12 months, and
created the frequently asked questions document for that
group. This document is now more or less a book in german
language, http://www.koehntopp.de/php. The FAQ team is currently
doing everything to make it worthwhile for printing and it will
be available in print in three months or so. Also, an english
translation of that document is planned and will begin shortly.
This will some time replace the current PHP FAQ at www.php.net,
or amend it.

During the work on the FAQ project I have learned a lot about XML
and XSLT. Basically, XSLT makes Template, ITX and friends obsolete.
It is part of PHP (thanks to the Sablotron extension by Sterling)
and it is a standard, not a hack. Also, to create the very same
functionality that Template offers you can use simplified
stylesheet syntax. That turns

<html>
 <body>
  <h1>{TITLE}</h1>
  Welcome, {USER}!
 </body>
</html>

into

<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xsl:version="1.0">
 <body>
  <h1><xsl:value-of select="$title"/></h1>

  Welcome, <xsl:value-of select="$user"/></h1>
 </body>
</html>

BUT it offers you all the power of XSLT, too, if you choose to care
about it AND it is supported by a lot of fine tools like XMetal and
XmlSpy, while Template isn't, AND it is built into any recend PHP 4
interpreter, if that interpreter has been baked correctly.

Such functionality makes the discussion which Template should become
part of PEAR kind of moot, as the ways of the future are XML and XSLT.
Learn them and use them, their simplified forms are just as simple
as Template is, and they are much more powerful and better supported
than Template, any Template, ever will be.

Also, in the article http://www.koehntopp.de/kris/artikel/websec/
(english at
http://www.devshed.com/Server_Side/Administration/WebSecurityI/
and http://www.devshed.com/Server_Side/Administration/WebSecurityII)
I talked about the main issue for web application security,
input validation. Ulf has done much work in this area, and much
better than I ever could, with his reformed and reengineered OOH Forms.

During his work, Ulf experienced many severe performance problems,
and while analyzing the reasons for that I learned a lot about
where and why PHP spends time. In a single request, PHP not only
has to read a lot of lines of source in order to generate bytecode,
but also has to create quite a complex object framework in order
to represent the data structures needed by Ulfs OOH Forms. It uses
all this code and data to service this request, and then simply
forgets it.

PHPLIB sessions and PHP 4 builtin sessions suffer from a similar
problem, as PHP lets all session variables die at the end of the request
in order to resurrect them on the next page. This is nice from a
christian point of view, but very impractical: You cannot serialize
any ressources, and this is a problem in principle which cannot
be cured.

The Zend cache tries to address the other half of the problem, because
it keeps compiled code in memory, obviating the need to recompile
the same code for each request again and again, but it does nothing
to keep data in memory.

Both, sessions and the cache try to fight different symptoms of the same
disease, the PHP version of Alzheimer, but they do not cure the actual
problem.

Imagine a single PHP server process, independent of a web server. If you
request a PHP page from a web server, a stub server API would gather all
needed request parameters, ship them to the PHP server process, that
process would produce the result page, and ship it back to the web
server
process. That process would send the generated page back to your
browser.

In order for the PHP server not to stall, it would have to be
multithreaded.
PHP can do that, already. Since the PHP process is a process different
from the web server, it need not run as the wwwrun user, but can be in
fact
any user, and could even be chrooted where the web server cannot.
Finally,
there is no need for a single PHP server, but instead you could start
different PHP servers for different applications, running under
different
user IDs and with different chroot() directories. This would greatly
increase application security.

Since the PHP server is a long running process, it can keep compiled
code
in memory just so. No need for a code cache at all, because the server
process does not die and does not forget.

Regular PHP variables would be forgotten at the end of a request just as
in normal PHP scripts. That is, normal PHP scripts would run in a PHP
server unchanged. They would not even know that they are running under
the PHP server SAPI, unless they ask for the sapi_name().

But our PHP server could not have a special array
called $SHARED[], which is NOT cleared at the end of a request and which
is not private to a single request thread but shared by all requests.
Because these variables are part of a single Unix process, and that
process
does not end, you could even keep ressources in this array, like
database
connections, image handles or open files. This finally allows for
proper ressource pooling and usage instead of lame pconnects().

One would wish for another array $SESSION[], which is just a shorthand
for
$SHARED["sess_".SID][]. Using the $SESSION[] array, you'd simply store
things
you wanted to remember in that array and they would stick around on a
per session basis. No page_open(), no session_start() needed.

Simple, compatible and easy to understand. And much more powerful than
any
session management library could ever be.

Thus, the PHP server would not only solve the compiled code problem,
but also solve the problem of forgotten variables and improve the
PHP session handling considerably. I see little sense in improving
session handling in PHPLIB, or PHP, (or http://bwcache.bware.it/,
http://apc.communityconnect.com/ or even the zend cache). They are
the strategically wrong solutions to the problems at hand. A PHP
server would be much better and more powerful.

My future work will be away from PHPLIB, but not from PHP. There
will be a lot of activity on german-faq <email protected> (german
PHP FAQ) and mysql-faq <email protected>, and there will be some
research in the area of PHP application servers like the one I
projected above. Much of this work will make parts of PHPLIB
obsolete, or improve PHPLIB in some way, so there will be (indirect)
benefit for PHPLIB users. But my work on PHPLIB can be wrapped
up in "been there. done that. there's no t-shirt." :-)

Thank you all for your input and patches,
        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/

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>