Stanislav Malyshev 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?
Hi Stas, Sorry, just a confusion of language on my part. ext/zip relies on libzip, an external lib that uses malloc/open and zlib directly. pecl/phar has built-in zip support based on php internals, it uses emalloc/streams which is what allows zlib/bz2 to be optional deps. Pierre and I are talking about merging efforts, which would benefit everyone. "libifying" the zip support in pecl/phar would be a relatively simple task, although some of the features are phar-specific, such as opendir() support. ext/zip would need to copy the generic opendir() stuff we use to get that (it scans all files to figure out which ones are in a directory, which is O(n) but works). zip support is only a small part of phar's features, merging all of phar's features into ext/zip would not make any sense and would confuse folks tremendously, such as being able to create tar archives with ext/zip :). Hopefully, the question of how the zip support will eventually end up looking (inside phar, phar/zip merge, new php zip lib) is kind of a non-issue. I'm very confident Pierre, Marcus, Steph and I will be able to work out the best solution for both ext/zip and pecl/phar, the main question at this point is bundling phar. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
