Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34978
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.178.248 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Sv/Tqf350Y8/YakBzfyP/99bDQWxOUU8S/HhEQq3KlP6mJxc2c8SpWzjT5N31brMwLakoca01Tf8StHhyR2xKa57dyB8QvnyBHAJx2I34DGFMyhnicWyVXmzFBJJ680pfZXXzODt+Ddv0ABZjswl2C5IK/UhIwFDn33rIDPuWJk=
Message-ID: <fe05d1540801281124n18055993jdc5ad8a832b25f88@mail.gmail.com>
Date: Mon, 28 Jan 2008 20:24:01 +0100
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "Gregory Beaver" <greg@chiaraquartet.net>, 
	"internals Mailing List" <internals@lists.php.net>
In-Reply-To: <479E2455.4040508@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <479E1152.50301@chiaraquartet.net> <479E2455.4040508@zend.com>
Subject: Re: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
From: pierre.php@gmail.com ("Pierre Joye")

Hi Greg,

On Jan 28, 2008 7:52 PM, Stanislav Malyshev <stas@zend.com> 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.
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.

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.

- crypt support

- Zipstream (not like the previous point), inline zipped data stream.
Like what you can see in many java-based web services.

- 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

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 :)

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org