Please remember that you can help on these subjects. To participate, please contact us.

If you have comments, critics, or new ideas, feel free to add a comment below.

1 - In PHK

1.1 - Build unit tests

Importance/Priority: 9/10

Build PHPUnit-driven unit tests for every PHK class.

1.2 - Comparison benchmarks

Importance/Priority: 5/10

Need to think about typical scenarios to compute the PHK overhead in different configurations (different cache systems).

1.3 - Finish the API documentation

Importance/Priority: 6/10

Finish commenting the source files and generate a complete API/Xref documentation for PHK_Creator and Automap.

1.4 - Better PHPUnit integration (Done - version 1.4.0)

Importance/Priority: 3/10

Today, the unit tests we have embedded in our demo packages are executed by including ther AllTests.php script. In the future, the behavior of the PHK test feature must be more similar to the original PHPUnit behavior:

• must allow to run parts of the tests, not just 'AllTests': '@test' would accept an optional argument to specify the test suite to run.
• must provide the same options as the phpunit command.

Could use a syntax like : php package.phk @test [phpunit-switches]  [UnitTest]

where the default value for 'UnitTest' would be AllTests.

I am seeking volunteer(s) to handle this task, as it requires less knowledge of the PHK internals than other ones (like cache integration).

1.5 - Add a standard configuration mechanism

Importance/Priority: 6/10

Most software in the PHP world use configuration files. When ported to PHK, we have a potential problem there because a  package is read-only by definition.

So, we must propose a way to configure a PHK package. This must be simple, easy, extensible. Ideally, it should not require shell access (in webinfo mode), allowing to configure a software remotely through an FTP-like connection...

 I am currently thinking of such a configuration class, which would be activated through the webinfo mode.

1.6 - Put source code in a versioning system

Importance/Priority: 5/10

The accelerator should go to PECL. - > Done

The PHP code can go to PEAR, or to sourceforge.

1.7 - Improve the accelerator extension (Done in PHK pecl extension 1.4.0)

Importance/Priority: 6/10

Several functions and classes can be added to the accelerator extension, even if we don't want the whole PHK software to be ported in C. These modules should be added to the accelerator (by order of priority) :

• the _phk_prolog() function
• the PHK_Mgr class
• the Autoload class
• the PHK class
• the PHK_Cache class

1.8 - Support Content negotiation

Importance/Priority: 1/10

This feature would be used mainly for documentation packages.

Combining multiviews and server-driven negotiation, it allows to choose the appropriate content to return, based on the browser preferences in terms of languages, charsets, and encodings. Would allow to build multi-lingual documentation packages (like the Apache manual).

1.9 - Support HTTP/1.x conditional requests

Importance/Priority: 1/10

Should be implemented in the web direct access mode controller.

Will first apply to plain subfiles (not PHP source). Could also apply to PHP scripts, via a new PSF modifier, but, by default, PHP script result must be considered as non cacheable.

Can be based on the http-conditional library.

1.10 - Differentiate exceptions

Importance/Priority: 1/10

Today, the PHK code only uses the 'Exception' class. But there can be several reasons for exceptions to be thrown, and, as long as we don't use more precise classes, the 'catch' blocks cannot differentiate between exception causes. Especially true in the stream wrapper, where any exception is considered as 'File not found'.

We should add at least the following types :

• PHK_FileNotFoundException
• PHK_LogicException
• PHK_IOError_Exception
• PHK_InvalidArgumentException

Then, we will differentiate exceptions in the catch blocks.

Some of the needed exception types are already defined in SPL.

2 - In the PHP interpreter

Here we list some changes to the PHP software, which would benefit to PHK.

2.1 - Cache interaction

(2008/01) Done - subject to approval by the PHP core maintainers

Importance/Priority: 9/10

The main improvement in PHK version 1.3 is cache integration and delayed mounts. In most cases, the requested subfiles are retrieved from the cache without having to physically access the archive. This cache integration uses the 'user cache', not the 'opcode' cache.

But PHK is compatible with opcode caching, thanks to the fact that mount points are computed to uniquely correspond to the physical PHK package file (using the same logic as the caches: use a combination of device number, inode, and modification time).

So, the next step will be to have cache systems provide entries for the PHK subfiles in their opcode cache. When it is achieved and combined with the PHK accelerator, the performance overhead of the PHK runtime layer should become negligible.

2.2 - The 'include_path' issue

Importance/Priority: 9/10

This is a major difference between a PHK package and a 'regular' package (where the files are 'real' files, in a 'physical' directory tree). For different reasons, it is impossible in PHP, today, to have a 'stream wrapper' URI in the include path. As PHK's subfile access is done through a stream wrapper, it means that, when a software is packaged in a PHK archive, it is impossible to put one of its virtual subdirectories in the include path.

There are several reasons :

• First, a trivial one : unfortunately, the ':' character is used both in the stream wrapper path syntax and as path separator under Unix. So, a stream-wrapper path cannot be part of the include path. This one could be worked around if, internally, PHP maintained its include path as an array instead of a string. We could also recognize the ':' character as a separator only if it is not followed by two '/' chars.
• But it would be useless because of the way the stream wrappers were added to the PHP core. The previous file access code was migrated to a wrapper, named the 'plain' wrapper. But the code used to resolve relative file specs through the include path was not moved to the upper layer. Now, when a file specification arrives at the upper layer, it analyzes it to determine which wrapper it must send it to. And, when it is a relative path, without any 'stream wrapper prefix', it goes to the plain wrapper, which can resolve the include path, but is unable to undertand a stream-wrapper path.

There are several possible solutions :

• when building a package, filter the code through a set of smart str_replace() calls : this is what must be done today for software like phpMyAdmin, which extensively use relative paths. Complex, hard to validate, generally cannot be fully automated. This is a temporary solution, but definitely not a satisfying one.
• authorizing stream-wrapped URIs in the include path : most PHP core experts consider that it would create a lot of security holes. A recent addition to PHP6 can open a track: a stream wrapper can be marked as 'local', allowing it to be used in include/require directives. Other stream wrappers will be considered as remote and won't be able to provide some code to the interpreter (cross site scripting protection). So, we could use this addition to autorize only 'local' stream-wrapped paths in the include path.
• Another approach, probably better in terms of security, is to add the possibility to use file access handlers. Such handlers would be called before a stream access is attempted by the PHP interpreter (only for relative paths). Each handler would have the possibility to return another path (an absolute one) which would be used in place of the original one. This way, it can become possible to simulate include paths and a 'virtual' current working directory (see next chapter).

2.3 - The 'current directory' issue

Importance/Priority: 9/10

A similar issue is related to the concept of current directory, as the chdir/getcwd() functions are built on top of the corresponding libc functions and they don't support stream wrappers. So, the concept of 'current directory' is handled by the plain wrapper.

What does it mean ?

• First, that it is impossible to reference a relative path in a PHP source file, when it is packaged in a PHK archive.
• It also means, as a consequence, that, when you prepare your source files to build a package, you have to modifiy every relative file access you have in your code to a path relative to the source file's pseudo directory by prefixing it with 'dirname(__FILE__).'/'.
• This way, you can keep your source code compatible between the 'plain' version and the PHK version. PHAR authors suggest replacing relative file paths by fixed URIs, which is not possible for PHK as the mount point is dynamically computed at mount time. The problem with this approach is that the same code cannot be used for the plain version and the PHK version, which is a major drawback to convince software authors to switch to PHK.

I think that the best idea so far is the addition of file access handlers as detailed above.

For more information on this subject, Greg Beaver recently did an interesting suggestion to improve the security when executing some PHP code through a stream wrapper.

2.4 - Extending the autoloader to functions and constants

Importance/Priority: 7/10

Today, Automap indexes and loads classes and interfaces transparently. But, as it also extracts function and constant names from the code, it is ready to handle them too. The only missing link is an autoload hook for functions and constants in the PHP core.

Most php-internals people consider this as low priority because the only autoloaders they know are primitive filename-based autoloaders. With such autoloaders, autoloading functions is useless as it would require to write one function per file ! The situation is different when you consider map-based autoloaders like Automap, as they can handle an unlimited number of symbols per file. Using such an autoloader along with PHK could provide the same kind of features as PHP C extensions : include a package file once, and then call functions without explicitely including anything else.

To implement this, we should add a second argument to the _autoload callback. This argument would contain the type of symbol we are searching : Automap::T_CLASS, Automap::T_FUNCTION, or Automap::T_CONSTANT. This would :

• preserve the compatibility with the existing autoloaders (maybe loading a class when we actually need a function, but it is not a major annoyance as names generally do not conflict that much).
• provide backward compatibility as an autoloader supporting the 'type' argument could declare it as optional, with a default value of 'class'. So, if it is called by an old interpreter, with only one argument, it will search for a class.

We also need to add a second optional boolean argument to function_exists() and defined().

3 - Others

3.1 - Ioncube integration

Importance/Priority: 3/10

The Ioncube loader does not accept to execute PHK subfiles. It is quite sad because PHK would perfectly complement Ioncube's features.

3.2 - Standalone executable files (CLI mode)

Importance/Priority: 1/10

Combining an embedded PHP interpreter with one or more PHK archives, we can develop a kit to build standalone executable files of PHP applications.

I keep this feature at a low priority because PHP is still mostly used in web environments. But, if some CLI projects, like PHP-GTK, become more widely used, it can become an interesting feature.

3.3 - Others

PHK is a natural complement for a lot of PHP tools : IDEs, PHP encoders, license managers (PHPAudit).... If you're maintaining/distributing such software and would like to integrate it with PHK, please contact us.

Last update : Saturday, 24 March 2012

Average user rating

   (0 vote)