On Jan 28, 2008 9:38 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote: > 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,
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. > 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. > > 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"; 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://.."); 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. > > - 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. It is easy to fix in libzip too but that's not a priority right now. Especially not before the new IO infrastructure is in place. 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. 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? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- 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}