Has anyone heard of any project designing such a thing (a la J2EE servlet engine)?
And by “servlet engine”, I mean a daemon that runs at least one PHP application and accepts requests to it. That is, a daemon would run (using some simple, standardized API) and load one or more PHP applications. Then, when the web server got a request for that servlet, it would pass it along to the servlet engine, which would then run the PHP application (only interpreting it once but executing many times), and, instead of forking more applications, it would (since we have good threading in the 2.6 kernel of Linux at least) create a new thread of the application for additional requests, sharing all application- and session-level data.
With something like this, I would be much more at ease using PHP 5 to its potential.
Sounds like Apache 2 (which is threaded, right?) and an opcode cache like turck mmcache (for the only interpreting once requirement). Granted, there’s nothing defining an application/servlet structure for your scripts, but you might see that as beneficial (no such structure is imposed).
By the way, turck provides a very nice cross-platform shared memory API for some interprocess communication, if you need it.
Pretty cute idea if somewhat of an abomination. The new OO features in PHP5 (including interfaces and abstract classes) would make a resonably clean implementation of a PHPlet container as a PHP CLI socket server. As one way to do it…
Well, first, as the complexity of the language increases, I find it much more difficult to justify using advanced OO language features that will be interpreted on every single request.
Second, application-level and even (cached) session-level data can remain in memory instead of being loaded on every request.
So, especially for larger, enterprise-level applications, you’re ensured that there’s minimal processor work required per-request.
I use the J2EE servlet engine as an example because it’s an excellent example of how this can be done. It just requires actual threading (or good interprocess communication, which is inferior) to share application-level data between threads.
I use the J2EE servlet engine as an example because it’s an excellent example of how this can be done.
Not only is it an excellent example of how it can be done, it is done and is what you should use if you want to build applications in the style you describe. Java is easy to deploy and develop in, plus it is incredibly well supported.
However, if you want to build applications where persistent application data is stored in standard subsystems like databases or a filesystem, where applications are built with basic OO language features plus a number of advanced procedural language features, and are built without having to resort to threading, then PHP is the system for you!
Both are proven to be a scalable and enterprise ready. You lucky guy. You can take your pick.
I disagree. I think a container for a servlet-type PHP scripts is a great idea. Put simply, it brings all the performance and scalability advantages that Java Servlet containers have to a huge user-base who like using PHP. There’s nothing to say that the class interface needs to be exactly the same as HTTPServlet. As long as it is a life-cycle based API, the similarities can end there. There’s always room for improvement. I think if someone wrote a thread/processor manager in C which loads the PHP engine and implements the API’s life-cycle, it would kick **** on the Java equivilent.
Basically you’d have the simplicity of PHP combined with the unparreleled speed of C and the zend engine. And then there’s all those resource optimisation abilities of the C language that Java could not hope to emulate.
It would take a long time to produce a product mature enough to use commercially, but I think it would be well worth it.
“Basically” if you combine the simplicity of PHP with the complexity of Java and your get … Java.
My point was you already have a system that does what you want: Java. And it’s really, really good for that style of implementation.
There is also another system that works differently: PHP. If you don’t like the shared nothing style then use Java or one of the may other options.
If everything should be like Java, why are you using PHP? Not having things like servlets and namespaces and threads is what makes PHP unique and useful. The Zend guys can tell you why better than I can. I know lack of an app server is what made PHP so popular in virtual server hosting and perform so well. Lack of threading makes is so you can call any external code you want without it having to be thread-safe. That has opened up a lot more useful code to PHP. Add this stuff to PHP and you have two Javas and have lost PHP.
You can put wings on a bulldozer or tracks on a airplane, but it does not make either better.
Strictly speaking, Java does not do this; a servlet engine and the Servlet API does it.
I really disagree with your characterization of PHP. As a language, it has nearly all the possibilities that Java has. Strictly speaking, the Java folks could have easily written an Apache module that would do a one-shot interpretation and execution just like PHP. That has nothing to do with the language and is a totally separate issue.
What does it matter? PHP is still significantly different from Java, especially when it comes to typing. Compared to Java, PHP is very loosely typed, and I might prefer it over Java for enterprise-class apps if there were a servlet-type engine for it.
Again, “servlets” are not part of the language. I think PHP should have (optional) namespaces, and I would be surprised if we didn’t see POSIX threading capabilities in PHP soon.
The way PHP is executed by the web server has nothing to do with the language itself. I’m not asking anyone to change the way PHP is executed. I’m just wondering if the servlet option is available.
I think you’d find that Java performs extraordinarily well on the server, and the lack of an app server for PHP has just made it easier to program for (which is its biggest advantage over languages like Java).
I would agree that it’s made PHP much easier to program for.
I think arborint is right, you said you want a container for enterprise-level application, but if you develop such application, I think you can easily install an app server and use JSP/Servlet instead of PHP.
And we could also just use perl to munge up text for simple web sites, but we don’t - we use php. The point that existing tools can do the job is moot.
I think deanpeace deals with arboint’s observations quite comprehensively so I won’t try to make the same points over again. However, I think an analogy is in order.
PHP started out as a CGI script. Now when someone came along and decided to make it into an apache module, someone could have said “wait a minute, if you want an apache module, you could just use mod_perl.”
What aborint is saying is the same thing. No one is talking about “Javar-ising” PHP. PHP will still be PHP if you ran your PHP scripts in a life-cycle container. I think you need to understand that life-cycle based containers a just a design pattern, not a new technology. I don’t think there’s anything wrong with borrowing the idea of the servlet framework design. People could have continued to build web apps with Java using CGI, but someone came up with a neat idea to make it more efficient - they didn’t change the languge, they built a purpose-made framework to improve HTTP interaction. Building such a framework won’t change PHP, it will still be the same simple language.
The main difference will be that your PHP script doesn’t have to terminate with every HTTP request. This can only be a GOOD thing. It has potential for massive performance/scalability improvements. At the moment, CGI, modules, and SAPI framweworks do not offer this due to their one-shot execution per request model.
Tezza, I don’t mean that they are going to change the language, I’m just wondering if it’s worth making efforts, 'cause you can just use JSP/Servlet for that.
In my opinion, I suspect it is worth the effort. The performance improvements could be massive. It wouldn’t be easy to implement though, there are a lot of issues to deal with. It should be pretty trivial to write a proof-of-concept with a command-line PHP socket listener, but this will never bring you the desired solution. Ultimately, the container will have to be written in C as are the apache modules and SAPI modules so that it can parcel off threads on an as-needed basis. Another advantage of this scheme is that we no longer have to rely on the web-server’s memory management system. We’d be free to manage the memory resources how we want. We would also have the opportunity to improve the thread-safety for file-writes and other things like application level variables.
And we could also just use perl to munge up text for simple web sites, but we don’t - we use php. The point that existing tools can do the job is moot.
Actually my point was that it is WHY existing tools do the job that matters. Perl started as a better shell script. Java as a run anywhere C++. PHP as a easy to use CGI. And that is still pretty much where they still excel. Off course the OO guys whine for the same stuff everywhere and hence the confusion because languages start to look the same. But the systems those languages live in are very different.
As a language, it has nearly all the possibilities that Java has. Strictly speaking, the Java folks could have easily written an Apache module that would do a one-shot interpretation and execution just like PHP. That has nothing to do with the language and is a totally separate issue.
Everything may have the same possibilities but it is the choices that make the difference. No app server, threads, etc. are a few of the many decisions that make PHP the useful tool it is. There are other sets of tradeoffs you can make that are successful too. But there are always tradeoffs.
The performance improvements could be massive.
Proven not to be true. App servers are just a different way to achieve the same thing. If anything they often slow things down because of the overhead and complexity they add.
Sure, the same advantages that PHP has over any other Java class. It will be PHP, not Java, so all the PHP advantages apply. It’s easy to use, it doesn’t have to be strictly OO, it has a big user-base, and is more fun than writing in a compiled language
I’m sure others have their own reasons why they prefer writing PHP scripts over Java classes. Using a framework won’t alter this any more than other frameworks like WACT, Krysalis, papoon, Ambivilance or whatever…
Alaso, a mature implementation of the idea may eventually be orders of magnatitude faster than Java.
