Another itch that really had to be scratched: the current pecl4win website is not really too user-friendly. I tried to tack some new features on the existing coebase:

• making available compiled versions of the pecl extensions released as stable packages (current pcl4win only builds from cvs source, making it a though choice for sysadmins to put thos dlls in production)
• add a few links back to the main pecl site
• add supports fro rss feeds of every extension/platform/combination thereof
• add a wee bit more info (page titles, table columns and sorting, etc...

The results can be found here

Since I maintain the PHP version, and AJAX is so ubiquitous nowadays, I figured out I would port the library to javascript, keeping the exact same API, as an exercise to hone my js skills. More details here.

The original php port was by David Holmes. More details about the changes I made are available on my blog. You can see the source code also here.

My very own personal itch to scratch: allows to consume webservices from inside an Oracle 9+ database, even if Java is not enabled.
Faster, buggier and easier to use than the default oracle SOAP packages (unless you use JDeveloper, that is...)

NOTE: as of June 2005 I have become an active developer of the original php-xmlrpc lib. All the work is now carried out in the main trunk. The extended version of the lib has been virtually surpassed both in terms of stability and features.

Mission: Build an ODBC-like thingy that will work across as many databases and operating systems as we can.

Use case: pull data from an Oracle DB running on Windoze into a Sybase DB running on Slowaris, with no db client drivers available for installation on the remote platform.

Features:

1. Written in PHP, runs on multiple platforms
2. Uses ADODB as DB access library: allows user to connect to many different databases
3. Uses XML-RPC as transport protocol: with many libraries existing in many languages to allow other people to write new clients / new servers
4. XML-RPC works over HTTP: routable, flexible protocol, deployed across firewalls and so on
5. Forget high throughput, low latency and in general performance. We are aiming at flexibility

Implementation steps:

1. OK Define an xmlrpc format that represents a recordset, preserving as much information is needed but no more
2. OKCode routines that convert this XML representation from / to ADODB native recordset objects
3. OK (Unplanned step) Patch the xml-rpc library used in order to provide support for compressed HTTP requests/responses (needed to move around large recordsets) and as many different xml charset encodings as possible
4. (work in progress) Define and implement xmlrpc-services used to execute queries on remote databases
5. (work in progress) Write an ADODB database driver that transparently connects to a remote database using the xml-rpc services defined above
6. OK (Unplanned step) devise a different connection driver and provide conversion routines for using SOAP as transport (server side implemented in Java)
7. (work in progress) Write a simple PHP script to be used as a data-moving service: execute query on source database, insert retrieved data on target database

Da code: it is available as part of the EXTRAS package for the php-xmlrpc library since release 0.2. Go grab it here.
Comments abound inside the code. There are even some installation instructions and examples.
Prerequisite PHP libraries: adodb and php-xmlrpc

Lame idea isn't it?

Goals:

1. Check a set of PHP files to retrieve as much info as possible, such as minimum and maximum PHP versions it will work with, dependencies on webserver / OS / extensions and so on...

Note that a similar package exists in the PEAR repository: PHPCompatInfo. It has better support for detecting PHP 5, but lacks detection of parameter count used in function calls.

Implementation steps:

1. Write a simple PHP parser (partially done, to be substituted with the PHPDoc parser)
2. Write a parser for the PHP online documentation, that will extract all the information about the php APIS: for each function we need
   • syntax declaration(s)
   • PHP version requirements (includes any additional function parameters added in successive releases)
   • OS requirements
   • extensions requirements
3. Write a script that uses API data (collected in an XML file) to parse PHP projects files

Known limitations:
Due to the interpreted nature of the language, the proposed goal is theoretically impossible to achieve. Problems include:

• usage of include and require: PHP scripts included using run-time info (e.g.

  require($a);

  ) cannot be determined at parsing time
• usage of eval: eval'd constructs cannot be examined at parsing time; same applies for call_user_func and call_user_func_array
• careful PHP coding that provides workarounds for different setups is hard to detect (e.g. a string manipulation function that will use the mbstring extension if it is installed and utf8encode otherwise)

Da code: WILL BE AVAILABLE SOON!