Pierre Joye wrote: > Hi Greg, > > On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > >>> Current status of phar addresses most of these criticisms: >>> >> Looks impressive, great work! >> >> >>> phar implements zip support with native PHP code, enabling some features >>> >> I am a bit confused about native PHP code here - we are talking baout an >> extension, right? So what exactly is meant here? >> Also, as I understand, there are features that ext/zip missed and phar >> extension needs. Any reason not to add them to ext/zip? >> > > Exactly and I'm rather surprised to see this post given the recent > efforts to export the Zip symbols to allow any extension to share the > zip features. Most of the discussions have been public on pecl-dev. > I expended considerable energy in this direction, but shortly after succeeding in getting the symbols exported, I began to run into limitation after limitation, and these were all intrinsic design problems in libzip, this was why I implemented the new zip stuff. I'm sorry if my communication was less-than-ideal, I have no intention of operating in dark alleys or behind closed doors, and have been emailing you offlist every step of the way as well as onlist for all changes that involved ext/zip directly. > There is some private discussions about our respective plans, even > today. I can say that the goals and APIs are different, there is a > need for both extensions (zip will never provide what phar does for > the application archive and pahr will never go as far as zip for the > zip format support), that's my understanding of the current situation. > I agree, both extensions are needed for the API differences. ext/zip is focussed on data users and is very good for that purpose, whereas phar is designed for php applications. However, it is inaccurate to say phar's zip format support is inferior to ext/zip. Phar's support of the zip file format is actually more extensive than libzip's in that it supports extra fields for files, bzip2 compression per-file, and is more easily extended. For instance, adding encryption support to phar's zip implementation is trivial compared to adding it to libzip. Neither extension supports split files, which is something that might make sense for ext/zip, or zip64, but zip64 would also be trivial to add to phar, 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. > For the record on this list, we also have a lot of work in progress > with the libzip developers and myself to add many new features. The > short list is: > > - custom stream support (like in libgd or libxml), allowing native (as > in operating system native supports) IO functions, bringing the > maximum portability and integration (we can use php stream as well as > soon as php supports large files > 2Go, I did not follow this topic, > maybe it is already in place). The stream works both in read in write > mode. > phar uses PHP streams, so if there is a 2 GB limit, this will affect phar until it is fixed. > - crypt support > this, interestingly, was raised in a private conversation with a developer over the weekend as a major must-have for closed-source apps, as they could distro as an encrypted zip, so I am fully in favor of implementing this in phar with the help and support of those who would use it. The stuff is all there in pharzip.h, all we need is the crypto and implementation details (for instance where does the key go? ini setting?). > - Zipstream (not like the previous point), inline zipped data stream. > Like what you can see in many java-based web services. > This is a limitation of phar I have been thinking about for a few days without a fleshed-out solution - currently bundling an archive inside of a phar archive is possible, but the stream URL does not support accessing internal phar archives. We may implement a mount-like thing a la PHK (Francois, if you are listening, this would be a great time to help implement PHK's better features in phar).
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"; > - Drop of the open files system limit for the amount of entries used > at the same time. This limitation was rather annoying but necessary to > insure the consistency and safety of zip creation > This is already fixed in phar's zip implementation. When reading files, phar has at most 2 open file pointers per phar archive, one for uncompressed and one for compressed files. > However, my point remains intact, I'm not in favour of having phar > included. Unless there is an improved cooperation with the community > (in large) to create this application-archive format. It would really > rock to have a standard format designed, approved and adopted by all > PHP developers and projects. At this point we can bundle it or it may > be a chicken-egg problem :) I am proposing phar precisely for this purpose - it's time for open discussions with all interested parties. I have had discussions with representatives from several projects privately, but now I would like to take the discussion public because I believe phar provides a foundation on which to build a standard format, while providing extreme flexibility for non-standard niche projects. An important feature of phar I had not mentioned which may alleviate the need to decide on an exact format is that Phar can convert from phar => zip => tar. The code looks like this: <?php // assume myphar.phar.zip is some application we downloaded $a = new Phar('myphar.phar.zip'); $a->convertToTar(); ?> convertToPhar()/convertToTar() can accept an optional compression argument Phar::GZ or Phar::BZ2 to compress the entire archive. 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}