Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO From: Kristian Köhntopp (kk <email protected>)
Date: 10/13/00

Sebastian Bergmann wrote:
> Regarding PHP's lacking Application Server abilities the following
> was mentioned:
>
> - Distributed Applications
> - permanentely running PHP Application, that's not (entirely)
> http-request driven

A PHP application server would be a multithreaded co-process
to the web server. It would receive parameters from a web server
module or CGI program by some sort of RPC (preferably fast RPC,
not SOAP or WDDX, but something you do not need to parse) and
would then produce some sort of output being shipped back to
the calling program.

By being a coprocess, the system could have variables (including
ressources such as Oracle connections or arbitrary sockets) that
are living longer than a single request. It could "cache"
precompiled code by simply keeping it in memory, and being
threaded, code sharing would be easy. This would enable PHP
coders to prototype things like true connection sharing (the
server could keep a variable number of database connections
open, which are then passed around between threads to serve
requests) and model something like a transaction server.

By being a coprocess, it would be easy to implement a simple
scheduler, which could run PHP functions or methods based on
time, accumulated memory or other criteria.

> > > - Native support for Load Balancing
> >
> > What does this mean besides using a database backend for sessions,
> > and round-robin dns or similar?
>
> This was what I mentioned in a talk at the congress, I was told
> that Java application servers provide more sophisticated means
> for this.

Java has mechanisms and deployment scenarios in which a single
web server distributes its RPC calls not to a single application
server, but to any number of such servers. The server having the
lowest load at the moment will process the request.

There are different deployment models possible, for example making
application state moveable (only possible with non-ressource variables,
as sockets, image handles and similar stuff is not easily passed
around betwenn machines). A different, and in my opinion more
interesting model would bind sessions upon creation to different
application servers and not migrate them, as this keeps the ability
to have ressources as part of a session.

> > > - support for large scale development
> > > (options comparable to the "use strict" and "-w"
> > > modes of perl)
> >
> > Can you be more specific? error_reporting(E_ALL) is
> > standard development procedure for me, and helps a
> > fair amount...
>
> I do not come from the "Perl world", I directly started
> with PHP 3 back then, so I don't know exactly what "use strict"
> or "-w" are good for, but error_reporting(E_ALL) seems to be
> a good start for debugging capabilities, yes.

Even more interesting would be an optional, not OPTIONAL, strong
typing model, especially with objects. We had that discussion
before, but here is the core of it again: In large scale projects
it would be immensely helpful if I got an error if I created
a $this->somevar by assignment which has not been declared by
var $somevar. Also, again as an OPTIONAL component, the equivalient
to DIM I AS INTEGER, that is, more strongly typed variables, would
be useful in large projects.

> _But_ what are the dreams / plans / visions for the future
> of PHP so that this state of "excellence" persists?

The strengths of PHP, compared for example to Java, are the
impressively flat learning curve and its extremely good rapid
prototyping capabilities. The strengths of Java are the much
better scalability in terms of load scalability as well as in
terms of lines of code (LOC) scalability. Also, Java is better
suited for component reuse at the moment, and has better debugging
(the latter is about to change, with Zends and with Nexidions
toolkits approaching availability).

Basically, you could take a HTML designer, show him echo and
<? ?> and have him create dynamic code immediately. This person
is immediately useful for very low end dynamic design, and will
gradually absorb more and more programming knowledge, MAKING MONEY
WHILE HE OR SHE LEARNS.

This is usually not the case in Java, where there must be some
formal introduction to programming, to compilers, to development
methodology and other stuff before the single first line of
useable code will come from that person. With university level
design methodology and terminology being abundant in the Java
community, this can be several months of learning.

All in all, PHP knowledge is cheaper and pays for itself
while learning.

The main idea is to keep the advantages of PHP, but add the
more useful features of Java to PHP to make it competetive in
the high end application space. There is dire need for this,
that much was clear from the congress: Even with PHP4, which
was introduced to solve the scalability problems of PHP3 in
the first place, people are using PHP for projects larger than
the language was designed for.

> there will be soon the next generation: web sites and
> applications are going to share their data.

CORBA, SOAP and .NET are needed for 100% buzzword compliance
here (abstract RPC interface, doing ONC RPC, DCE RPC, Corba,
DCOM, SOAP, XML-RPC?), as well as XML, XSLT, and of course
a large collection of payment interfaces. Perhaps a payment
abstraction would be in order, similar to the DBA interface,
or the ADODB or DB_Sql classes.

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>