Re: Re: cvs: php4 / TODO

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/