Some postings have emerged that discuss the implementation of threads in PHP. John recently referred to an article published in the English PHP Magazine and Georg wrote some valuable comments.

Shane did some work on a threads extension available in PECL a couple of months ago. The extension is very experimental.

There’s no plan to incorporate multithreading into PHP5 - if we believe the experts

I am not sure about how SRM can help with multithreading. At least it provides persistency across requests which allows to emulate a multithreading environment yourself in PHP (left aside if it’s a good idea e.g. to implement priority management of “threads” in PHP itself and not the Zend engine). Comments are welcome.

What’s missing is a threads implementation similar to Java or Ruby, especially with features like:
- set and manage the priority of threads
- define threads as daemons
- allow for synchronized threads (see Ruby’s Mutex Class)

From the Prevayler Web site [1]:

“Prevayler is the most reliable Free Software Prevalence layer we are capable of providing for Java.”

“With Prevalence we are finally free to create true object servers and use objects the way they were intended all along.

We are able to use any algorithm, data-structure and query language we please. We are no longer constrained to the ones provided by database and application servers which must run on disk data-blocks.

We believe the whole OO community is finally free to recover from the atrophy caused by database and application server restraints. We no longer have to distort and maim our object models to satisfy their limitations.

We no longer have DBAs imposing us database layout restrictions. We have freed them to do something more useful.

We have set fire to the table-models on our walls. We have deleted our database creation scripts. We no longer have to keep them updated.

We no longer have to license, install, configure and maintain a database and application server every single time we want to develop, demonstrate or deploy our systems for any of our clients. Give us a Java VM and we are good to go.”

via Reto Bachmann-Gmuer, private email

[1] http://www.prevayler.org/

Reto pointed me to the Jena Semantic Web Toolkit [1] which has some RDF-specific APIs and query language implemented. Jena is part of HP Labs Semantic Web Research [2].

via Reto Bachmann-Gmuer, private email

[1] http://www.hpl.hp.com/semweb/jena.htm
[2] http://www.hpl.hp.com/semweb/index.htm

The Java Specification Request 170 [1], which defines a uniform application programming interface (API) for access to content repositories, might be a way to go for Open Source Content Management interoperability [2]?

Some analysts say that “June 2003 will see a reshuffling in the content management industry with final adoption of the Java Specification Request 170 (JSR 170) standard” because it addresses the main problem of CMS:

” Web applications such as Web sites, portals, shops or catalogues interact with content. These are held in content repositories, which are generally part of a content management system. The e-business sector has been faced with major challenges, because each CMS manufacturer uses its own repository API. It is not easy to exchange applications (for example, a database conforming to SQL), so integrators are forced to master various APIs, work with different application developers such as portal manufacturers, and adapt their products to a very wide range of APIs. This situation is not satisfactory for customers either - once you’ve decided on a content management system, it’s not easy to change your mind.” [3]

[1] http://www.jcp.org/en/jsr/detail?id=170&showPrint
[2] http://blog.bitflux.ch/p625.html
[3] http://www.serverworldmagazine.com/monthly/2003/01/java.shtml