As some of you might have noticed, I've been a bit busy lately creating new PECL extension - sphinx.
The extension provides an interface to a feature-rich fulltext search engine Sphinx written by Andrew Aksyonoff.
We (Andrew and me) made our best to keep the extension as compatible to the pure-PHP API (shipped with Sphinx) as possible in order to make the transition easier, so if you're already using PHP API, you only need to remove (or comment out) the include "sphinxapi.php"; line and enable the extension in your php.ini.
Yes, it's that easy.

I also added a documentation for it to the PHP manual - http://php.net/sphinx, it covers all the functions, but lacks code examples at the moment (contact me if you want to contribute some, it's very much appreciated).

To install the extension you need libsphinxclient (it's shipped with Sphinx since v0.9.8), here is a short installation guide:

# tar -xzvf sphinx-0.9.8.tar.gz
# cd sphinx-0.9.8/api/libsphinxclient/
# ./buildconf.sh
# ./configure && make install

After that PECL will do all the work for you:

# pecl install sphinx-beta

I've got no complaints so far, so I suppose I can call it stable in a month or so.
Until then I'll continue to gather feedback (please use PECL bug-tracker if you encounter any problems, thanks!).

According to GCOV reports, PHP test coverage has recently exceeded 55%, which is really good number, but still not enough. It took us about 2 years to get the last 5% and I believe most of the kudos should go to IBM people, who continue to contribute lots of new tests.
I hope that the Testfest will help us to speed up this process.

It took quite some time for me to think it over and prepare new libHaru site - libHaru.org.
Nevertheless, it's finally online and I'm going to continue maintaining the library, new bugfix release is on its way.

Though I don't think I can do all the maintenance job on my own - some help is required with Windows builds and other things like the documentation, which needs some cleanup (even though it's in a good shape at the moment), so volunteers are very welcome.

Anyway, if you need to produce PDF files, libHaru is the answer.
If it doesn't satisfy your needs or even lacks something crucial - let me know, I'll see what I can do.

Just so that you know what I think about that CLA thing:


Make It Open Or Go Away

PDOv1 was initially a small project created and maintained mostly by 1-2 persons.
Even though it was quite small, it turned out to be a kind of monster which nobody really likes or understands.
Oh.. and did I mention that it never actually worked?

And now we're being forced to have PDOv2, which is of course very much different from PDOv1: it's being developed by a secret group of people (which includes some mysterious "vendors") aand.. it requires signing a legal paper it you want to participate or even read its spec.

PDO does not need a CLA, PDO needs *CARE*.

Doesn't matter how much "vendors" participate in PDO, it's going to be a total failure as long as nobody cares about it.
That was the biggest flaw of PDOv1 and CLA won't magically fix it.

The docs generated by the brand new docu build system PhD ([CVS], [releases]) written by Hanness Magnusson, after several months of development are finally online!

Feel the difference:
   With the old OpenJade/DocBook it took 40-60 minutes to build 'many htmls' version of the manual.
   With PhD it takes less than 2 minutes to build all three formats (`phpweb`, `one big html` and `many htmls`).

Kudos to Bjori!

As you know, there are lies, damned lies and statistics benchmarks.
So here are some more template benchmarks: http://template-bench.iliakantor.ru/, prepared by Ilia Kantor.
Curiously enough, Smarty is on the 5th place, right after the stuff written in C, so think twice before saying it's slow.

IMO it's time to make the development process more organized.
This is my version of what I would like to see as an official set of rules for PHP community.

PHP Seven Commandments

1. Thou shalt obey the Release Master.

2. Thou shalt not commit any patches except for bugfixes after RC stage has started.
Even bugfixes must be discussed with the release master before committing.

3. Remember the coding standards and keep them holy.

4. Thou shalt not forget to add comments to thy code, especially if the code is tricky.

5. Thou shalt not fix a bug only in one of the branches unless it did not exist in the others.
The rule of thumb is to fix it in HEAD first and then backport it.
Forwardporting is not appreciated unless it happens in a matter of hours.

6. Major development goes in HEAD, other branches are created for bugfixes and minor improvements.

7. Thou shalt discuss all new features in internals@.
If nobody pays attention to your proposal, it makes little sense to implement it.

Alexey Rybak has recently rolled out new bugfix release of his template PHP extension - Blitz 0.5.7.
This release fixes a number of minor problems including memory leaks and possible invalid reads and does not affect functionality or speed in any way, so the extension is still blazing fast, but even more stable now.
See more about Blitz here (benchmarks included).

1. Have you ever needed to generate PDF files on-the-fly? (Yes/No)
2. If yes, what did you use for that? (PDFLib/libharu/Other)
3. Did you try PECL/haru or libharu itself? (Yes/No)
4. Are you interested in open source library for PDF generation (written in C)? (Yes/No)
5. Would you like to take part in development/maintenance/testing of such a library? (Yes/No)

I'm thinking to move libharu development under the PHP.net umbrella (Takeshi Kanno, the original author, has just agreed to that), just as we did with GD, but I'm not yet sure if there is a need for it in the community.
At the moment libharu development is de facto stopped because the author lacks time for it and I personally think it would be a great pity to lose this kind of library.

So what do you people think?
Are there any people willing to help?