Pierre Joye wrote: >>> for ext/zip, or zip64, but zip64 would also be trivial to add to phar, > > It is already implemented. We are working on portability issues. > That's why I put the custom stream support as the top priority, it is > the way to go to solve almost portability issues.
Which is? zip64? This is not implemented in any public releases of libzip, or in any of the 5 branches of zip's bundling of libzip, is there a public repo that I have missed that I should be looking at? >> as the header formats are already in pharzip.h waiting to be >> implemented, should the need arise, for instance, to support InfoZIP >> zips with UTF-8 file comments/filenames. > > By no mean you can rely only on UTF-8. It is handy but it is not what > zip specs say. OS specific encoding is sadly the way they work. InfoZIP does have a specific extension stored as an extra field. This is mentioned in appnote.txt. ZIP64 support for UTF-8 is also explicitly mentioned, perhaps you thought I was talking about a different area of the spec? >> Accessing individual files within the zip directly is easily done with >> Phar::webPhar(), you just put the phar in your web path, and append the >> local path to the internal file. In other words, to access file >> "path/to/blah.jpg" in phar "myphar.phar.zip.php" in the docroot of >> localhost, you browse to >> "http://localhost/myphar.phar.zip.php/path/to/blah.jpg"; > > I really don't like this feature, but it may be handy for apps :) I > prefer what we do in zip, fopen("zip://...","..") or > imagecreatefromjpeg("zip://.."); Of course, identical syntax works with the phar:// stream wrapper if ext/phar is present. > An interesting feature for both zip and phar would be the ability to > pipe the read stream to another stream (ie stdout) instead of writing > the read data into a file/variable. stream_copy_to_stream() works great in this arena, not sure any additional features are needed. <?php $fp = fopen('phar://blah.phar/path/to/blah.jpg', 'rb'); stream_copy_to_stream($fp, STDOUT); ?> > Now that we have moved one step forward, I would like to make a > suggestion: we should stop the ext/A vs ext/B. It is pointless (we > agreed that goals are different) and counter productive. I still think > that in the end you should rely on ext/zip for the zip operations. The > "limitations" you are talking about could be fixed very quickly in > ext/zip without waiting for the custom stream support (for the file > handles, checksum, etc.). The write for the php stream support is also > possible without too much work, but it is an extra step I did not want > to take, I prefer to get the new IO in place before. Here are the issues with ext/zip that are must-fix showstoppers for pecl/phar to use ext/zip: 1) zlib/bz2 must be an optional dependency, currently zlib is required. The design of libzip is such that the zlib library is required in order to load, not just to compile it. 2) libzip compares local/central directory records and calculates crc on load for every file. This must be done on access to a specific file in order for it to be truly viable for phar (lazy validation). 3) libzip has no support for extra fields for either file or archive. We use them to store file permissions in pecl/phar. Everything else phar's zip implementation provides is a "would-be-nice-to-have" such as small performance enhancements on access to a file by name (phar's implementation is O(1), while libzip's is O(n) because phar uses a hash table and libzip uses a vector). > However I find your actual positions confusing and each mails bring > opposing arguments about the shared work between other archives > extension and phar. Can you clarify your view please? I'm not sure which opposing arguments you're referring to, but I will try to clarify. My view is simple and hasn't changed from the first message. pecl/phar has specific needs in a zip implementation that are not currently available from ext/zip. I am more than willing to use ext/zip should these enhancements become available. It also might make sense to consider having ext/zip use phar's zip implementation, and I am open to that possibility. pecl/phar devs hope to limit the number of required dependencies in order to best benefit end users who often have little to no control over their configuration. In addition, we'd like to see the best implementation possible of these archive formats. I would have optional dependencies on pecl/archive and pecl/zip, but pecl/archive does not build on windows, and pecl/zip has the issues I listed above. Note that removing phar's internal zip support and instead using pecl/zip would make phar's zip support optional, another consideration in the mix, but I am more than willing to do this. I also would fix up pecl/zip/lib if I really thought it was possible, but taking into account my limited abilities, the only way I see that it could be done is with a redesign of libzip. I defer to you and the libzip developers to prove me wrong if there is a way to satisfy pecl/phar's needs in a zip implementation, as you are far more accomplished and experienced in libzip internals. Now, here's the actual state of things at cvs.php.net: pecl/phar has the zip support it needs internally. libzip does not yet have the zip support pecl/phar needs. Isn't all of this argument moot until ext/zip/lib has the needed features? I'd love it if we could steer away from talking about pecl/phar's zip support, as this is really a side note to the main proposal. pecl/phar also supports tar archives, based on an implementation Dmitry Stogov wrote as a proof-of-concept. More importantly, I want to note that the manual does not seem to have built recently, and you'll have to read the documentation at http://docs.php.net/manual/en/book.phar.php to see the most up-to-date stuff. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
![http://localhost/myphar.phar.zip.php/path/to/blah.jpg"](http://localhost/myphar.phar.zip.php/path/to/blah.jpg"){kind=link}