On Mar 15, 2005, at 7:41 PM, cshmoove wrote:

read my reply to Christian. as i mentioned, i'm working on another project which already has infrastucture for dealing with similar issues. i simply noticed that it could be adapted for the PAR/PHAR idea. IOW, the extension will be written whether or not we do the implement web archives.

BTW, i gave your blog only a cursory glance, so i can't comment in depth. however, i will say that the format addresses your issue of not having to unpack. the file is memory mapped and cached, so all resources are available without file operations beyond the initial open resource types are string, int, arrays (numerically indexed), tables (hashes of any other type), utf16 string and binary (arbitrary sized). resource fallback is standard (eg. /path/to/resource/en_US/ -> /path/to/resource/en/ -> root )

What I was trying to suggest was that this was really two things. One is an extension that would present a tar file as a file system:


require_once 'tar::///path/myresources.tar/path/index.php';

or

require_once 'tgz::///path/myresources.tgz/path/index.php';

The extension could, of course, cache the tar file in memory and build some internal data structures to optimize multiple accesses into the file. I think this would be a good general addition to the standard PHP distribution.

This combined with the HALT patch would be a killer combination for distributing PHP applications in one file without unpacking.


Then, on top of this tar layer would come the higher level resource location API. The API wouldn't care if its base files were located in an archive or on the native file system, or in another kind of stream wrapper.


if the tar extension's implementation of file_exists('tar:://path/to/resource/en_US/resourcename') is fast enough, couldn't the resource location layer even be native PHP?

The reason I suggested the OS X Bundle system was because it implements its resource location capability with xml metadata (info.plist) on top of a plain file system and I thought it might lend itself to such a division of labor.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to