They are all subjective, except for big users base that can lead to creating some new technology, like PHP-servlet, I wrote about here
I think you are not really clear about what you are asking for. At the top you wanted " (only interpreting it once but executing many times)" (i.e. compiled) and at the end you like 'is more fun than writing in a compiled language."
If you are looking for speed then use an accelerator and put your sesson files in a RAM disk. That wil achieve your goals of compile once and memory resident application data without having to turn PHP into Java.
I guess it comes down to if you are interested in a specific method in achieving your goal, use a system that implements that method. If you are interested in achieving your goal using PHP, then find the PHP way to do it.
Now that is an interesting idea - remembering that you can put objects in a session variable.
Douglas
Yes, you can serialize objects (with care). And getting data from a RAM file system is faster and lower overhead than going through an app server. The PHP Way is using existing and proven sub-systems not inventing new ones.
That is a global programming principle rather than something invented by PHP. It is better to re-use something that works than to fix the wheel which isn’t broken.
If anything, the “PHP Way” as you call it is more a case of making the wheel easier to use to aid re-use; the “proven sub-system” ideology of not reinventing things existed before PHP!
Douglas
RAM disk would be fast, but don’t forget memcahce - wikipedia, slashdot and livejournal are using it: http://pecl.php.net/package/memcache, home page: http://www.danga.com/memcached/
Another solution; again a sub-system that is not language specific. Interesting because you can spread the cache across multiple servers. More complex and powerful than the simple, single server, RAM disk solution. Thanks nucleuz.
But wait a minute. I hear that the J2EE people brag that J2EE will transparently handle failover for them. So if you’re using a Web app and the server you’re connected to fails, you will notice nothing because another server takes over. I can’t see how this is possible unless session data is stored somewhere other than in RAM on a specific server.
The servlet engine idea may be a good one, but I think it needs to be explored in more detail before we can make educated guesses about just how good it is.
You’re assuming that we’re building something from scratch. Suppose we already have a working PHP application–perhaps a large one–and circumstances change so the “style you describe” becomes more relevant. Even if you’re right, switching to Java might not be a viable option.
Even if you’re right, switching to Java might not be a viable option.
Then solve it using a PHP style solution (and there are many) don’t ask for servlets, threads, multiple inheritence, etc. etc.
For example, if you want failover for sessions then store them in a database and use one of the many failover solutions for databases.
I like the idea of having the possibility of running php in a servlet-like engine. I’m thinking of proper control over thread sensitive applications, real-time systems etc.
Saying that one could use Java is true, but not an argument for why PHP couldn’t benefit from having such an engine. Where Java is heavy weight and might scare users off, I think PHP should focus on being lightweight, flexible, powerfull and accessible. Just like what PHP makes a success today.
It may also give PHP a new boost in terms of establishing one very strong framework (or framework standard/specification) and improve the enterprise readiness of PHP. That could become a ‘plus’ over the numerous Java solutions out there (Tomcat, WebLogic, WebSphere etc).
I’d like to pose a new question to this very interesting discussion: how would you see a serphplet 
being realized? Would this be similar to PHP-GTK? Would this be OO only, or also procedural (begin, end, wait, goto…)?
Well, but if you have to work with different framework and etc. I wouldn’t say that it’s very lightweight and easy for beginners.
Serphplet? If you mean servlet, then why on earth do you nead PHP-GTK for that?
Maybe you’re right. I’m not advocating anything; I’m deliberately keeping an open mind about it because I don’t think I have enough information to decide. There may be circumstances in which a PHP servlet engine would be useful.
Yes, I was implying just that. I don’t think you understood the intent of my comment. I wasn’t touting the superiority of J2EE, I was pointing out the similarity to what you can do in PHP.
True. But I didn’t say it would be easy. There’s no way any beginner will have an easy time on complex material. In my opinion, php and java are just tools. And, like mentioned earlier in this thread, a servlet engine would just be another ‘feature’ of the product PHP.
Edit2: I do think the implementation should be the KISS (Keep It Simple Stupid) way.
Mind the winking smiley…
Well, because the lifecycle of a servlet (http://www-306.ibm.com/software/webservers/appserv/intro/wastutor8.htm) resembles that of an application (PHP-GTK) more than a script that gets executed within the webserver environment.
Edit: I’m not saying that php-gtk should be used, but that some of the thoughts/ideas behind it may turn up again in a php servlet engine…
By the way: http://sourceforge.net/projects/phplet/
I have modified PHPLet and cleaned it up some and it only handles sequential requests (as PHPLet also had multiple processes, which I took out, but could put back in). I also added session management and a database pooling. The only real problem I have found is that any modifications you make to your servlet class requires the service to be restarted because once the servlet class has been included() it cannot be unloaded.
If there is much interest I can create a sourceforge project and put the code up.
Derek
that’s not the whole truth, but: then you would rely on Classkit to be on the server… ( point is: you can, if you really want to 
)
Renaming the class solves the problem but it won’t remove it from memory which is what the ideal solution would be.
Finally! All of this chatter and nobody knew of this?
The only reason I can see going against something like a PHP servlet engine, which is essentially what SRM (the above link) is, are the potential problems of running these in LVS style clusters. If I’m not mistaken, this is something the JavaServlet people still have not figured out.
Anyway, with an LVS style cluster can come the idea or concept of shared nothing, which makes these systems simpler and more robust in terms of dealing with failure (not including the database level). The drawback here being that there is no persistence the way the Java guys want to see it, nor is there any true persistence across the entire web pool (or server farm) other than the database, at which point, you are still dealing with serialization. OTOH, msessions looks to be a good solution for this issue in the future. I just don’t know if they yet have an automatic fail over mechanism.
Anyway, SRM development has been dead for some time, which is a damn shame. Something like this, with the incorporation of msessions and persistent connetion(s) to a database (as opposed to the connect-query-dis-connect pattern) would be a boon for PHP development in load balanced highly available setups.
Cheers,
BDKR
For sure. Remember, SRM is based on PHP4. PHP5 brings with it a host of advantages which would warrent re-visiting this or similar concept.
DB connection pooling would be a major major boon for database performance and connection management. At the moment running out of connections with pconnects can be a real possibility unless db config and web server config is tightly controlled by a very aware sys-admin/dba (who work closely together). Even so, you still have to make compromises on what would be an optimal upper limit for allowed connections.
A system like msession the protocol would be able to be implemented as part of the container itself (rather than as a separately managed extension).
At the point is, none of this is possible while running PHP in any of the currently available modes - cgi, module, sapi…
The only disadvantage I suspect is the fact that long-running scripts may be more prone to memory leaks. This is more of an issue since PHP has so many extensions, adding to the probablity that at least one of them may be buggy if used by a long-running script. This fear could be unfounded but it may be a possibility.