Hi Steph, On Jan 28, 2008 8:38 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > 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. > > I think until the zip features were shared the library's limitations hadn't > been too obvious. There is no limitation per se. There is room for improvements like the ones I listed. There is a huge amount of users and a very small amount of bug reports or support requests, it simply works for almost everyone :). > > Most of the discussions have been public on pecl-dev. > > There is some private discussions about our respective plans, even > > today. > > Not that I'm aware of... I'm not sure to understand what you mean here. There was discussion on pecl-dev and there is a current private discussions about phar and zip :) > > 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. > > What exactly would we need to do to improve cooperation? What we did not do for PEAR and why it took too long for pear to be widely adopted (and there is still work to be done in this area). The problem is that you can't force a given format. I have no magic solution but I think we should find something to get some of the major projets involved to get what they actually like to see and/or if what is done fits their needs. > 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 :) > > Well, that's why the aim is to get it bundled now. Because using the Phar > extension you can now optionally write phars that can be opened by: tar (+ > bzip2/zlib), zip (including Windows Explorer), or plain PHP, either CLI or > through a browser, using the default stub; it's about as flexible as anyone > could want it to be. There's still also the option to write phars that > require ext/phar enabled before they can be read, which personally I think > is a bad idea but Marcus wanted it that way. I think it is a good thing to require ext/phar even for the read operations. It certainly allows a shit load of optimization and tricks that will never be possible otherwise. But Greg or Marcus will give us a better answer :) 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
