Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Adding pecl/zip to 5.2 »

Adding pecl/zip to 5.2

php.internals

Pierre Joye

20 years ago
Hello, Many people (incl. php devs) asked me if I can include zip in 5.2.0. Ilia thought it was too late in the game and planed to do it in 5.2.1. I like to have it in, as experimental. Please note that it intoduces a new class called Zip, but I never saw a php zip implementation named Zip. +1/-1/0? Cheers, -- Pierre

Antony Dovgal

20 years ago
On 19.07.2006 18:34, Pierre wrote:
> Hello, > > > Many people (incl. php devs) asked me if I can include zip in 5.2.0. > Ilia thought it was too late in the game and planed to do it in 5.2.1. > > I like to have it in, as experimental. > > Please note that it intoduces a new class called Zip, but I never saw a > php zip implementation named Zip. > > +1/-1/0?
-0. I would rather move more extensions from core to PECL, than from PECL to core. But to make it possible we need at least to make PECL version aware, so maintainers can release packages for different PHP versions without having to use thousands of #ifdef's. So I'm basically against it, but I can live with this as long as the package is actively maintained.
-- Wbr, Antony Dovgal

Mark Evans

20 years ago
> > > I would rather move more extensions from core to PECL, than from PECL to > core.
From my experiences the problem with this is many shared hosts wont install non core modules, so the more modules moved from core to pecl the less flexible php will be and the less use it will be. I understand the need to keep the core code maintained and as clean and lean as possible, but we also need to look at what developers need to create applications that can be used with mass virtual hosting. Regards Marco

Sean Coates

20 years ago
> From my experiences the problem with this is many shared hosts wont install > non core modules, so the more modules moved from core to pecl the less > flexible php will be and the less use it will be. > > I understand the need to keep the core code maintained and as clean and > lean > as possible, but we also need to look at what developers need to create > applications that can be used with mass virtual hosting.
This is a valid point, but it represents a chicken-and-egg problem. Shared hosts are used to deploying PHP Proper and ignoring PECL, because in the past, core was the only repository for everything. As PECL grows in popularity (and as users demand more PECL installations), we can hope this these hosts become more flexible. At least that's what _I_ think. S

Mark Evans

20 years ago
> Shared hosts are used to deploying PHP Proper and ignoring PECL, because > in the past, core was the only repository for everything. > > As PECL grows in popularity (and as users demand more PECL > installations), we can hope this these hosts become more flexible.
I agree and I also hope this is the case. Regards Marco

Lukas Smith

20 years ago
Sean Coates wrote:
>> From my experiences the problem with this is many shared hosts wont install >> non core modules, so the more modules moved from core to pecl the less >> flexible php will be and the less use it will be. >> >> I understand the need to keep the core code maintained and as clean and >> lean >> as possible, but we also need to look at what developers need to create >> applications that can be used with mass virtual hosting. > > This is a valid point, but it represents a chicken-and-egg problem. > > Shared hosts are used to deploying PHP Proper and ignoring PECL, because > in the past, core was the only repository for everything. > > As PECL grows in popularity (and as users demand more PECL > installations), we can hope this these hosts become more flexible. > > At least that's what _I_ think.
I think we should make this a PHP6 todo item. A new major version is a better opportunity to get a change of minds, than a creeping slow change, which is about creating sufficient pain in our users so that shared hosters finally get the clue. Until then we should add extensions that we think are reasonably frequently required and move out the ones that we deem obscure. I think zip is quite reasonable to get added. As for the coordination of PECL packages that are symlinked to internals, it sounds like this really needs some thinking before PHP6, because there are already a number of extensions affected and it does sound like its a little bumpy. regards, Lukas

Richard Lynch

20 years ago
On Wed, July 19, 2006 11:51 am, Marco wrote:
>> I would rather move more extensions from core to PECL, than from >> PECL to >> core. > > From my experiences the problem with this is many shared hosts wont > install > non core modules, so the more modules moved from core to pecl the less > flexible php will be and the less use it will be. > > I understand the need to keep the core code maintained and as clean > and lean > as possible, but we also need to look at what developers need to > create > applications that can be used with mass virtual hosting.
Let's move MySQL to PECL, and then the hosts will have to re-think that brain-less choice. :-) I'm actually half-serious here... Move enough crucial things to PECL, and they'll start being smart about their install, or they'll start losing customers.
-- Like Music? http://l-i-e.com/artists.htm

Mark Evans

20 years ago
> > > Move enough crucial things to PECL, and they'll start being smart > about their install, or they'll start losing customers.
Or PHP will become non viable as a language and people with start using ruby on rails ;-) Regards Marco

Derick Rethans

20 years ago
On Wed, 19 Jul 2006, Antony Dovgal wrote:
> On 19.07.2006 18:34, Pierre wrote: > > Hello, > > > > > > Many people (incl. php devs) asked me if I can include zip in 5.2.0. > > Ilia thought it was too late in the game and planed to do it in 5.2.1. > > > > I like to have it in, as experimental. > > > > Please note that it intoduces a new class called Zip, but I never saw a > > php zip implementation named Zip. > > > > +1/-1/0? > > -0. > > I would rather move more extensions from core to PECL, than from PECL to core.
I agree here, I am also not sure whether picking the extremely short classname Zip is actually a good thing. Perhaps ZipArchive or ZipFile would be more fitting in the first place, not even considering the issue you can have with other libraries. Complaining against the name "Date" and then just going in another ext with "Zip" just feels wrong. Although the zip ext is a useful thing to have, I think it should stay in PECL as Tony says we're trying to move things to PECL... so a -1 from me on the current proposal to add ext/zip to core with the Zip classname. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Robin Ericsson

20 years ago
On 7/20/06, Derick Rethans <derick@php.net> wrote:
> Although the zip ext is a useful thing to have, I think it should stay > in PECL as Tony says we're trying to move things to PECL... so a -1 from > me on the current proposal to add ext/zip to core with the Zip > classname.
Seems silly to have a place like PECL where extensions can live their own life with their own release-cycles when people want to bundle every useless extension with PHP like it was before extentions began moving to PECL. regards, Robin

Antony Dovgal

20 years ago
On 20.07.2006 11:52, Robin Ericsson wrote:
> On 7/20/06, Derick Rethans <derick@php.net> wrote: >> Although the zip ext is a useful thing to have, I think it should stay >> in PECL as Tony says we're trying to move things to PECL... so a -1 from >> me on the current proposal to add ext/zip to core with the Zip >> classname.
> Seems silly to have a place like PECL where extensions can live their > own life with their own release-cycles
That's another problem for another offtopic discussion: "own release cycle" is just a myth, because of the "symlinks" used to link PECL extensions to core. You can't have, for example, development version in PECL and stable version in the core, you HAVE to stabilize your code before any PHP release, because it's basically the same code.
-- Wbr, Antony Dovgal

Michael Wallner

20 years ago
Antony Dovgal wrote:
> On 20.07.2006 11:52, Robin Ericsson wrote: >> Seems silly to have a place like PECL where extensions can live their >> own life with their own release-cycles > > That's another problem for another offtopic discussion: > "own release cycle" is just a myth, because of the "symlinks" used to > link PECL extensions to core. > You can't have, for example, development version in PECL and stable > version in the core, you HAVE to stabilize your code before any PHP > release, because it's basically the same code.
Well, an extension author could choose to import the extension to /php-src instead of creating a link, no? Regards,
-- Michael

Sebastian Bergmann

20 years ago
Antony Dovgal wrote:
> -0. > > I would rather move more extensions from core to PECL, than from PECL > to core.
I second that emotion.
-- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Sean Coates

20 years ago
> Many people (incl. php devs) asked me if I can include zip in 5.2.0. > Ilia thought it was too late in the game and planed to do it in 5.2.1.
I don't remember seeing a discussion on including Zip in core (perhaps I just missed it, but a quick search didn't turn it up). I think Zip is better suited as a PECL module. Tony mentioned another issue: the headache of maintaining PECL code between PHP versions. This is a valid point (and he can elaborate if he likes), but is a separate issue. IMO, core shouldn't grow for modules like this (and JSON -- but the JSON discussion certainly DID take place and the module seems tiny enough to be benign); the idea is to move non-essential modules OUT of the main distribution and into PECL, not the other way. -1 on Zip in 5.2.0 -1 on Zip in 5.2.1 S

Pierre Joye

20 years ago
Hello, On 7/19/06, Sean Coates <sean@caedmon.net> wrote:
> Tony mentioned another issue: the headache of maintaining PECL code > between PHP versions. This is a valid point (and he can elaborate if he > likes), but is a separate issue.
I'm very aware of the PECL issues and that's irrelevant in this current poll.
> IMO, core shouldn't grow for modules like this (and JSON -- but the JSON > discussion certainly DID take place and the module seems tiny enough to > be benign); the idea is to move non-essential modules OUT of the main > distribution and into PECL, not the other way.
The discussions to move it out never took place either, that's also a problem. Also consider this version as a complete new package, it fits in your definition. --Pierre

Derick Rethans

20 years ago
On Wed, 19 Jul 2006, Pierre wrote:
> Hello, > > On 7/19/06, Sean Coates <sean@caedmon.net> wrote: > > > Tony mentioned another issue: the headache of maintaining PECL code > > between PHP versions. This is a valid point (and he can elaborate if he > > likes), but is a separate issue. > > I'm very aware of the PECL issues and that's irrelevant in this current poll. > > > IMO, core shouldn't grow for modules like this (and JSON -- but the JSON > > discussion certainly DID take place and the module seems tiny enough to > > be benign); the idea is to move non-essential modules OUT of the main > > distribution and into PECL, not the other way. > > The discussions to move it out never took place either, that's also a > problem.
You can't move it out when it is not in yet... Derick

Pierre Joye

20 years ago
On Thu, 20 Jul 2006 09:44:38 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> On Wed, 19 Jul 2006, Pierre wrote: > > > Hello, > > > > On 7/19/06, Sean Coates <sean@caedmon.net> wrote: > > > > > Tony mentioned another issue: the headache of maintaining PECL > > > code between PHP versions. This is a valid point (and he can > > > elaborate if he likes), but is a separate issue. > > > > I'm very aware of the PECL issues and that's irrelevant in this > > current poll. > > > > > IMO, core shouldn't grow for modules like this (and JSON -- but > > > the JSON discussion certainly DID take place and the module seems > > > tiny enough to be benign); the idea is to move non-essential > > > modules OUT of the main distribution and into PECL, not the other > > > way. > > > > The discussions to move it out never took place either, that's also > > a problem. > > You can't move it out when it is not in yet...
It was in and moved out without much discussions. What I mean is that we have to discuss which extensions can or should be moved out, and on the lists. So we can do it the right way. -- Pierre

Alexander Pak

20 years ago
+1 I wish to see Zip in PHP, it's a popular archive and plus used in .jar implementation and .jar in its turn is used in other file formats, for example OpenDocument one.. On 7/19/06, Pierre <pierre.php@gmail.com> wrote:
> > Hello, > > > Many people (incl. php devs) asked me if I can include zip in 5.2.0. > Ilia thought it was too late in the game and planed to do it in 5.2.1. > > I like to have it in, as experimental. > > Please note that it intoduces a new class called Zip, but I never saw a > php zip implementation named Zip. > > +1/-1/0? > > Cheers, > -- Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- sincerely yours, Alexander Pak

John Coggeshall

20 years ago
On Wed, 2006-07-19 at 17:34 +0200, Pierre wrote:
> +1/-1/0?
+1 from me, I still to this day get people pestering me about my article on creating .zip files from pure PHP -- a real extension is clearly useful. John

Jani Taskinen

20 years ago
On Wed, 19 Jul 2006, Pierre wrote:
> Please note that it intoduces a new class called Zip, but I never saw a > php zip implementation named Zip. > > +1/-1/0?
-1 in core, PECL is the place for this. -100 for class called Zip for the same reasons why we can not have Date and TimeZone classes. --Jani

Pierre Joye

20 years ago
On 7/20/06, Jani Taskinen <sniper@iki.fi> wrote:
> On Wed, 19 Jul 2006, Pierre wrote: > > > Please note that it intoduces a new class called Zip, but I never saw a > > php zip implementation named Zip. > > > > +1/-1/0? > > -1 in core, PECL is the place for this. > -100 for class called Zip for the same reasons why we can not have > Date and TimeZone classes.
With the difference that I'm honest and do inform everyone. But your point is, in this case, wrong: - it is experimental and not enabled by default. Date is enabled by default - if it is enabled by default, it will not be before php6 at best, meaning it is a major version - I never saw any kind of code using Zip This extension was wrongly moved to PECL. It is time to fix this mistake. OpenDocument support and other zip based system justify this addition even more. --Pierre --Pierre

Marcus Börger

20 years ago
Hello Pierre, well Jan has a has a very good point here. Just as it was unlikely that a class called PDO had been implemented a hundred times, it didn't cause any namespace clashes. However it is fairly likely that some frameworks bring Zip support and have a class named Zip. If not then there probably is no mainstream use for a Zip class and inclusion to core makes little sense. So for me this falls clearly under the terms of our naming scheme (see [7] below) and shows we should extend this rule a bit to prevent obvious and very short names. Obvious here imo means terms that are likely to be used in a frameworks/applications. To me Zip definitively is. Apart from renaming i have nothing against moving it to core. Just a short note, you accused Derick of sneaking in stuff that was more or less decided, well obviously he could have done it early - hadn't he done much other work and haven't he been on vacation either. So thinking he did is fairly understandable, though i personally doubt that. But be it that. Why now do the same bad trick again, and that without even having dicussed the technical part of inclusion beforehand (like we did for date)? best regards marcus [7] Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CampelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension). Good: 'Curl' 'FooBar' Bad: 'foobar' 'foo_bar' Warning: this is no acusation...if you feel like you probably better not answer at all. Thursday, July 20, 2006, 1:11:24 AM, you wrote:
> On 7/20/06, Jani Taskinen <sniper@iki.fi> wrote: >> On Wed, 19 Jul 2006, Pierre wrote: >> >> > Please note that it intoduces a new class called Zip, but I never saw a >> > php zip implementation named Zip. >> > >> > +1/-1/0? >> >> -1 in core, PECL is the place for this. >> -100 for class called Zip for the same reasons why we can not have >> Date and TimeZone classes.
> With the difference that I'm honest and do inform everyone. But your > point is, in this case, wrong: > - it is experimental and not enabled by default. Date is enabled by default > - if it is enabled by default, it will not be before php6 at best, > meaning it is a major version > - I never saw any kind of code using Zip
> This extension was wrongly moved to PECL. It is time to fix this > mistake. OpenDocument support and other zip based system justify this > addition even more.
> --Pierre
> --Pierre
Best regards, Marcus

Pierre Joye

20 years ago
On Thu, 20 Jul 2006 09:51:37 +0200 helly@php.net (Marcus Boerger) wrote:
> Hello Pierre, > > well Jan has a has a very good point here. Just as it was unlikely
Jan?
> that a class called PDO had been implemented a hundred times, it > didn't cause any namespace clashes. However it is fairly likely that > some frameworks bring Zip support and have a class named Zip. If not > then there probably is no mainstream use for a Zip class and > inclusion to core makes little sense.
No mainstream use? Which other examples do you need? There is hundred of usages of the zip archives.
> So for me this falls clearly > under the terms of our naming scheme (see [7] below) and shows we > should extend this rule a bit to prevent obvious and very short > names.
Again, I have nothing against short names. We have to inform our users and prepare them.
> Obvious here imo means terms that are likely to be used in a > frameworks/applications. To me Zip definitively is. Apart from > renaming i have nothing against moving it to core. > > Just a short note, you accused Derick of sneaking in stuff that was > more or less decided, well obviously he could have done it early - > hadn't he done much other work and haven't he been on vacation > either. So thinking he did is fairly understandable, though i > personally doubt that. But be it that. Why now do the same bad trick > again, and that without even having dicussed the technical part of > inclusion beforehand (like we did for date)?
I still accuse him to sneak things in. He did it twice for the same thing. Don't compare apples and oranges. This thread is exactly what has missed for Date. Cheers, --Pierre

Pierre Joye

20 years ago
Hello,
> [7] Classes should be given descriptive names. Avoid using abbreviations where > possible. Each word in the class name should start with a capital letter, > without underscore delimiters (CampelCaps starting with a capital letter). > The class name should be prefixed with the name of the 'parent set' (e.g. > the name of the extension). > > Good: > 'Curl'
Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous. -- Pierre

Mark Evans

20 years ago
Why not delay Zip until 5.3 and make an E_STRICT or E_NOTICE in 5.2 for the Zip classname being a reserved word? In fact if we could come up with a list of class names php wants to reserve for itself then we could make them all raise notices so that people have time to fix their code. Regards Marco

Pierre Joye

20 years ago
Hello, On 7/20/06, Marco <markright@gmail.com> wrote:
> Why not delay Zip until 5.3 and make an E_STRICT or E_NOTICE in 5.2 for the > Zip classname being a reserved word?
It makes little sense as it is not enable by default. A visible entry in the NEWS and Changelog should be enough. Note that it is exactly what I proposed to solve the date class problem, but it is hopeless.
> In fact if we could come up with a list of class names php wants to reserve > for itself then we could make them all raise notices so that people have > time to fix their code.
Yes, I'm still wating a discussion about that, but it seems that I lost my last illusions about PHP being able to prevent troubles instead of acting in the hurry like we just did. --Pierre

Marcus Börger

20 years ago
Hello Marco, if we plan to include new classes and have E_STRICT (imo not notice) to inform about the inclusion with the next minor version update would be a good thing. To stay with the example at hand, inclusion then would go like accepting Zip during 5.2 phase. Adding the E_STRICT at the point the decision was done and then in 5.3 do the actaul inclusion. best regards marcus Thursday, July 20, 2006, 1:41:48 PM, you wrote:
> Why not delay Zip until 5.3 and make an E_STRICT or E_NOTICE in 5.2 for the > Zip classname being a reserved word?
> In fact if we could come up with a list of class names php wants to reserve > for itself then we could make them all raise notices so that people have > time to fix their code.
> Regards
> Marco
Best regards, Marcus

Mark Evans

20 years ago
> > if we plan to include new classes and have E_STRICT (imo not notice) to > inform about the inclusion with the next minor version update would be a > good thing. To stay with the example at hand, inclusion then would go > like accepting Zip during 5.2 phase. Adding the E_STRICT at the point the > decision was done and then in 5.3 do the actaul inclusion.
I agree this is a good idea. Although after 5.2 we could think about some core class names and mark them all as E_STRICT even if they wouldnt be included in the 5.x series. I think Pierre mentioned starting a new thread to look at what names PHP would like to reserve, I think it could be a good idea to start this sooner rather than later. Regards Marco

Marcus Börger

20 years ago
Hello Pierre, Thursday, July 20, 2006, 12:08:10 PM, you wrote:
> Hello,
>> [7] Classes should be given descriptive names. Avoid using abbreviations where >> possible. Each word in the class name should start with a capital letter, >> without underscore delimiters (CampelCaps starting with a capital letter). >> The class name should be prefixed with the name of the 'parent set' (e.g. >> the name of the extension). >> >> Good: >> 'Curl'
> Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
When Derick began with Date naming it different was rediculous, too. Why not ZipFile, ZipArchieve, ZipClass or PhpZip. At least the latter probably noone has used so far. And i can only repeat myself, it seems highly likely that there are classes named Zip out there. Best regards, Marcus

Derick Rethans

20 years ago
On Thu, 20 Jul 2006, Pierre wrote:
> > where > > possible. Each word in the class name should start with a capital > > letter, > > without underscore delimiters (CampelCaps starting with a capital > > letter). > > The class name should be prefixed with the name of the 'parent set' > > (e.g. > > the name of the extension). > > > > Good: > > 'Curl' > > Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
It is, but alternatives such as ZipFile, ZipArchive can work just as well. IMO the classnames should be nouns... and what does "Zip" itself really say? Derick

Pierre Joye

20 years ago
On 7/20/06, Derick Rethans <derick@php.net> wrote:
> On Thu, 20 Jul 2006, Pierre wrote: > > > > where > > > possible. Each word in the class name should start with a capital > > > letter, > > > without underscore delimiters (CampelCaps starting with a capital > > > letter). > > > The class name should be prefixed with the name of the 'parent set' > > > (e.g. > > > the name of the extension). > > > > > > Good: > > > 'Curl' > > > > Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous. > > It is, but alternatives such as ZipFile, ZipArchive can work just as > well. IMO the classnames should be nouns... and what does "Zip" itself > really say?
Do you really ask me what Zip say? For 99.999% of PHP users, I think it is pretty obvious, in a programming context with an extension called "zip", and even more when they have enabled it themselves. There is maybe a couple of people who will expect a kind a php based zipper, but really, do we care? It makes no sense to rename it (for all reasons I listed above). I can wait php 6.0 or until I eclipsed Methuselah's age. Users will suffer from your choices, not me, too bad. Cheers, --Pierre

Derick Rethans

20 years ago
On Thu, 20 Jul 2006, Pierre wrote:
> Do you really ask me what Zip say?
You miss the point. If you do "new Zip" ... then I've no idea what the object you get represents. However, doing "new ZipArchive" makes sense as then you know the object represents a ZipArchive for example. Just "Zip" doesn't say anything about the object so I consider it a bad classname. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Pierre Joye

20 years ago
On 7/20/06, Derick Rethans <derick@php.net> wrote:
> On Thu, 20 Jul 2006, Pierre wrote: > > > Do you really ask me what Zip say? > > You miss the point. If you do "new Zip" ... then I've no idea what the > object you get represents. However, doing "new ZipArchive" makes sense > as then you know the object represents a ZipArchive for example. Just > "Zip" doesn't say anything about the object so I consider it a bad > classname.
I have a good hundred (verbose) users (which mails me about it) out there, for example one of them is Alexander Pak, Summer Of Code Open Document project. They asked me many many things. One thing was to bring consistency to the API, move to a stable state and... bundled it as soon as possible. But they never had any kind of comments or questions about what is "new Zip". There will be more objects in the future, but not related directly to the zip itself or its properties (no ZipFile object for example). I'm thinking about iterators or helpers for complex operations. For these classes, yes, it makes sense to name them ZipIteratorXxx or ZipFooBar. --Pierre

Lukas Smith

20 years ago
Derick Rethans wrote:
> On Thu, 20 Jul 2006, Pierre wrote: > >> Do you really ask me what Zip say? > > You miss the point. If you do "new Zip" ... then I've no idea what the > object you get represents. However, doing "new ZipArchive" makes sense > as then you know the object represents a ZipArchive for example. Just > "Zip" doesn't say anything about the object so I consider it a bad > classname.
I am definately in the camp that wants zip handling in core, but I also think Derick's naming argument makes sense. regards, Lukas

Andi Gutmans

20 years ago
Although I don't want to clutter the list further, I do agree with Derick&Marcus on this. I actually like ZipArchive() better :)

Pierre Joye

20 years ago
Hi Andi, On 7/21/06, Andi Gutmans <andi@zend.com> wrote:
> Although I don't want to clutter the list further, I do agree with > Derick&Marcus on this. I actually like ZipArchive() better :)
You agree with Rasmus and Derick, as Marcus does want it in for all possible reasons. However, it seems to slowly have a majority for ZipArchive, it is then more acceptable for me. Even if I still think that Rasmus is wrong, the problem is not solved, the problem only begins. As soon as the extension is symlinked, I will rename the class. Cheers, --Pierre

Rasmus Lerdorf

20 years ago
Pierre wrote:
> On 7/20/06, Derick Rethans <derick@php.net> wrote: >> On Thu, 20 Jul 2006, Pierre wrote: >> >> > > where >> > > possible. Each word in the class name should start with a capital >> > > letter, >> > > without underscore delimiters (CampelCaps starting with a capital >> > > letter). >> > > The class name should be prefixed with the name of the 'parent >> set' >> > > (e.g. >> > > the name of the extension). >> > > >> > > Good: >> > > 'Curl' >> > >> > Curl is good but not Zip? Should I use ZipZip? Come one, it is >> ridiculuous. >> >> It is, but alternatives such as ZipFile, ZipArchive can work just as >> well. IMO the classnames should be nouns... and what does "Zip" itself >> really say? > > Do you really ask me what Zip say?
Well, in the US at least, Zip says Zip Code to me. Zip compression would be my second guess so it isn't completely obvious. -Rasmus

Pierre Joye

20 years ago
Hello, On 7/20/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> Well, in the US at least, Zip says Zip Code to me. Zip compression > would be my second guess so it isn't completely obvious.
It is a ZipCode, exactly. --Pierre

Rasmus Lerdorf

20 years ago
Pierre wrote:
> Hello, > > On 7/20/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > >> Well, in the US at least, Zip says Zip Code to me. Zip compression >> would be my second guess so it isn't completely obvious. > > It is a ZipCode, exactly.
And by the same logic, a Zip archive is a ZipArchive. Do a web search for "zip" and you will find that half of the first set of results are about zip archives and the other half are about zip codes. Why are you assuming zip automatically means zip archive to people? It certainly doesn't to me, but perhaps I am too much of a Unix guy so zip archives have never been of much use. -Rasmus

Alexander Pak

20 years ago
On 7/20/06, Marcus Boerger <helly@php.net> wrote:
> > If not then there probably > is no mainstream use for a Zip class and inclusion to core makes little > sense.
Hi, I took this from wikipedia( http://en.wikipedia.org/wiki/ZIP_%28file_format%29): ------- Microsoft has also included minimal built-in ZIP support (under the name "compressed folders") in later versions of its Windows<http://en.wikipedia.org/wiki/Microsoft_Windows> operating system <http://en.wikipedia.org/wiki/Operating_system>. Apple also included built-in ZIP support in Mac OS X <http://en.wikipedia.org/wiki/Mac_OS_X> v10.3 and later. Some software uses the ZIP file format as a wrapper for a large number of small items. Generally when this is done a different file extension is used. Examples of this usage are Java<http://en.wikipedia.org/wiki/Java_programming_language> JAR <http://en.wikipedia.org/wiki/JAR_%28file_format%29> files, id Software<http://en.wikipedia.org/wiki/Id_Software>.pk3/.pk4 files, package files for StepMania <http://en.wikipedia.org/wiki/StepMania> and Winamp<http://en.wikipedia.org/wiki/Winamp>, XPInstall <http://en.wikipedia.org/wiki/XPInstall>, and some OpenOffice.org<http://en.wikipedia.org/wiki/OpenOffice.org>document formats. The OpenDocument <http://en.wikipedia.org/wiki/OpenDocument> format usually uses the JAR file format <http://en.wikipedia.org/wiki/JAR_%28file_format%29>internally, so it can be easily uncompressed and compressed using tools for ZIP files.
-- sincerely yours, Alexander Pak

Edin Kadribasic

20 years ago
Jani Taskinen wrote:
> On Wed, 19 Jul 2006, Pierre wrote: > >> Please note that it intoduces a new class called Zip, but I never saw a >> php zip implementation named Zip. >> >> +1/-1/0? > > > -1 in core, PECL is the place for this. > -100 for class called Zip for the same reasons why we can not have > Date and TimeZone classes.
Comparing apples and organges here, eh? Tried to disable ext/date recently? FYU, ext/date is not only enabled by default, but it cannot be disabled. Even pcre can still be disabled. Edin

Derick Rethans

20 years ago
On Thu, 20 Jul 2006, Edin Kadribasic wrote:
> Even pcre can still be disabled.
That's on the todo for php 6 though. Derick

Edin Kadribasic

20 years ago
Pierre wrote:
> Hello, > > > Many people (incl. php devs) asked me if I can include zip in 5.2.0. > Ilia thought it was too late in the game and planed to do it in 5.2.1. > > I like to have it in, as experimental. > > Please note that it intoduces a new class called Zip, but I never saw a > php zip implementation named Zip.
+1 for inclusion of zip to 5.2.0. Zip is optional extension that is not enabled by default. Its a low-risk and very useful addition. Edin

Rainer Müller

20 years ago
Pierre wrote:
> Please note that it intoduces a new class called Zip, but I never saw a > php zip implementation named Zip.
Uh, well this already was on thedailywtf... See here, http://thedailywtf.com/forums/thread/80949.aspx Rainer

Pierre Joye

20 years ago
On Thu, 20 Jul 2006 04:27:19 +0200 mueller_rainer@gmx.de (Rainer Müller) wrote:
> Pierre wrote: > > Please note that it intoduces a new class called Zip, but I never > > saw a php zip implementation named Zip. > > Uh, well this already was on thedailywtf... > See here, http://thedailywtf.com/forums/thread/80949.aspx
If you read the thread it is obviously his mistake. Secondly, what does that have to do with our problems? The extension is not enabled by default and is experimental. If some people enables it in production (on windows or not) is not our problem. -- Pierre

Marcus Börger

20 years ago
Hello Pierre, actually i think we should no longer accept EXPERIMENTAL extensions in core, though from my view at pecl/zip it should have reached a stable state just right now, am i correct? best regards marcus Thursday, July 20, 2006, 12:05:08 PM, you wrote:
> On Thu, 20 Jul 2006 04:27:19 +0200 > mueller_rainer@gmx.de (Rainer Müller) wrote:
>> Pierre wrote: >> > Please note that it intoduces a new class called Zip, but I never >> > saw a php zip implementation named Zip. >> >> Uh, well this already was on thedailywtf... >> See here, http://thedailywtf.com/forums/thread/80949.aspx
> If you read the thread it is obviously his mistake. Secondly, what does > that have to do with our problems?
> The extension is not enabled by default and is experimental. If some > people enables it in production (on windows or not) is not our problem.
> -- Pierre
Best regards, Marcus

Pierre Joye

20 years ago
On 7/20/06, Marcus Boerger <helly@php.net> wrote:
> Hello Pierre, > > actually i think we should no longer accept EXPERIMENTAL extensions in > core, though from my view at pecl/zip it should have reached a stable > state just right now, am i correct?
Ok, it is getting really ridiculuous. Where have you found this idea? What does mean EXPERIMENTAL? It means that's the API can change, or that you should try it and help us to make it stable as soon as possible. Time to be serious now? --Pierre

Marcus Börger

20 years ago
Hello Pierre, Thursday, July 20, 2006, 11:15:05 PM, you wrote:
> On 7/20/06, Marcus Boerger <helly@php.net> wrote: >> Hello Pierre, >> >> actually i think we should no longer accept EXPERIMENTAL extensions in >> core, though from my view at pecl/zip it should have reached a stable >> state just right now, am i correct?
> Ok, it is getting really ridiculuous. Where have you found this idea? > What does mean EXPERIMENTAL? It means that's the API can change, or > that you should try it and help us to make it stable as soon as > possible.
> Time to be serious now?
I am but you obviously prefer to bring instable suff into core or what now? Until now my idea of Zip was a stable idea so you could easily have removed the tag file. The above said makes me thing that it is far away from stable otherwise you wouldn't again have insulted the one who did not share your opinion and that even without reason....calm down relax and play nicely Best regards, Marcus

Pierre Joye

20 years ago
Hello, On Thu, 20 Jul 2006 23:26:58 +0200 helly@php.net (Marcus Boerger) wrote:
> I am but you obviously prefer to bring instable suff into core or what > now? Until now my idea of Zip was a stable idea so you could easily > have removed the tag file. The above said makes me thing that it is > far away from stable otherwise you wouldn't again have insulted the > one who did not share your opinion and that even without > reason....calm down relax and play nicely
I play nicely and I'm not calm. You are clearly turning this simple question into a personal FUD. Like you did about the zip stream in pecl list (yes, I give you another reason to shoot it down). I will move to beta when we (the users and I) consider that the API will not change. That means that one can use in production without the risk to break everything on update. About the stability of the code, I think this extension is way more stable than its predecessor (which was in core) and as stable as many recent additions (from pecl or not). About adding experimental extension in ""core"", then please make a proposal. It will make other people start to release beta/stable package of untested code and without any users feedback about the API (which always ends to BC breaks). I'm not sure I'm going to like that. Cheers, -- Pierre

Pierre Joye

20 years ago
Hello, So I let Ilia decides whether it should be in or not. So far the relevant arguments are only about "moving ext to pecl and not the other way around", which is my opinion plain wrong (pdo, json, filter, etc..). The class name argument is none the less a sweet vengeance as its class name fits in our naming standards. Cheers, -- Pierre

Jared Williams

20 years ago
> Many people (incl. php devs) asked me if I can include zip in 5.2.0. > Ilia thought it was too late in the game and planed to do it in 5.2.1. > > I like to have it in, as experimental. > > Please note that it intoduces a new class called Zip, but I > never saw a > php zip implementation named Zip. > > +1/-1/0?
I would've preferred an unified package for handling multiple archives (zip/rar/tgz etc). Similar to what PDO does for databases, if it is going into core. Jared

Ron Korving

20 years ago
I was thinking the same thing. We can of course clutter the namespace with a class for every possible file extension we want to develop an API for, but maybe we can do the smart thing and do what PDO does for databases: present a unified API. I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they all do the same. In the end people will start realizing the PDO-road should've been taken from day one. I wish I had any experience with PECL to work something out right now, but I don't. If anyone's interested, I'd be willing to invest some time in constructing an API though (as a sort of first step in a proof of concept). - Ron ""Jared Williams"" <jared.williams1@ntlworld.com> schreef in bericht news:20060721112422.JLUB11710.aamtaout03-winn.ispmail.ntl.com@win2ks...

Pierre Joye

20 years ago
Hello, On 7/21/06, Ron Korving <r.korving@xit.nl> wrote:
> I was thinking the same thing. We can of course clutter the namespace with a > class for every possible file extension we want to develop an API for, but > maybe we can do the smart thing and do what PDO does for databases: present > a unified API.
I was thinking the same as well. But I don't think it is a good idea. For the simple operations, you can do it easily in php. I don't think there is a need for an internal implementation of such wrappers.
> I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they > all do the same.
They don't always do the same, that's the problem. Also I'm a fan of one need/one tool. PDO was needed because it is really a mess in the DB APIs. I would prefer to define some common API and have independent extensions. It will let us implement all format specific features or needs (which can be speed, compression level, etc.). Cheers, --Pierre

Richard Quadling

20 years ago
A compression wrapper like PDO would be great. And they do all do the same things more or less. Take data and compress it. Take compressed data and uncompress it. Not that different. On 21/07/06, Pierre <pierre.php@gmail.com> wrote:
> Hello, > > On 7/21/06, Ron Korving <r.korving@xit.nl> wrote: > > I was thinking the same thing. We can of course clutter the namespace with a > > class for every possible file extension we want to develop an API for, but > > maybe we can do the smart thing and do what PDO does for databases: present > > a unified API. > > I was thinking the same as well. But I don't think it is a good idea. > For the simple operations, you can do it easily in php. I don't think > there is a need for an internal implementation of such wrappers. > > > I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they > > all do the same. > > They don't always do the same, that's the problem. Also I'm a fan of > one need/one tool. PDO was needed because it is really a mess in the > DB APIs. I would prefer to define some common API and have independent > extensions. It will let us implement all format specific features or > needs (which can be speed, compression level, etc.). > > Cheers, > --Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

Pierre Joye

20 years ago
On 7/21/06, Richard Quadling <rquadling@googlemail.com> wrote:
> A compression wrapper like PDO would be great. And they do all do the > same things more or less. Take data and compress it. Take compressed > data and uncompress it. Not that different.
Then do it in PHP, it is very easy to create one for the simple operations (which seems to be what you are looking for). And you can start now or help the PEAR File_Archive maintainers to port their packages to php5 (and use the native functions). I'm ready to help or to modify the API as long as zip is not in the beta phase. No other language has such wrappers implemented nativelly and for those I use, I do not know any wrapper at all. Cheers, --Pierre

Richard Quadling

20 years ago
So where does this leave adding pecl/zip to 5.2? PDO is not core for Windows so should zip? On 21/07/06, Pierre <pierre.php@gmail.com> wrote:
> On 7/21/06, Richard Quadling <rquadling@googlemail.com> wrote: > > A compression wrapper like PDO would be great. And they do all do the > > same things more or less. Take data and compress it. Take compressed > > data and uncompress it. Not that different. > > Then do it in PHP, it is very easy to create one for the simple > operations (which seems to be what you are looking for). And you can > start now or help the PEAR File_Archive maintainers to port their > packages to php5 (and use the native functions). I'm ready to help or > to modify the API as long as zip is not in the beta phase. > > No other language has such wrappers implemented nativelly and for > those I use, I do not know any wrapper at all. > > Cheers, > --Pierre >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

Edin Kadribasic

20 years ago
Richard Quadling wrote:
> So where does this leave adding pecl/zip to 5.2? PDO is not core for > Windows so should zip?
PDO is bundled in the core PHP distribution. Pierre was not asking for Zip to be enabled by default, just to be a part of the distro. Edin

Lukas Smith

20 years ago
Edin Kadribasic wrote:
> Richard Quadling wrote: >> So where does this leave adding pecl/zip to 5.2? PDO is not core for >> Windows so should zip? > > PDO is bundled in the core PHP distribution. Pierre was not asking for > Zip to be enabled by default, just to be a part of the distro.
Yes, exactly. As for the PDO for archive format argument: The main reason for a base PDO extension was the idea of providing a framework for database extensions. The question now is if such a thing is necessary for archive formats? I think it would be sufficient to ensure that there is a common API for all common aspects. Since we are talking about OO here, all you need to do then is to use the constructor of the given format and you are done. So note for example that while PDO has a common constructor for all RDBMS it does not provide a common DSN format either. regards, Lukas

Pierre Joye

20 years ago
On 7/21/06, Richard Quadling <rquadling@googlemail.com> wrote:
> So where does this leave adding pecl/zip to 5.2? PDO is not core for > Windows so should zip?
PDO is not core on windows? I do not understand what you say here. --Pierre

Richard Quadling

20 years ago
I'm corrected by Edin. Misunderstood. So, why are some extensions bundled and not others? Surely all successfully built, non experimental extensions should be part of the distro? On 21/07/06, Pierre <pierre.php@gmail.com> wrote:
> On 7/21/06, Richard Quadling <rquadling@googlemail.com> wrote: > > So where does this leave adding pecl/zip to 5.2? PDO is not core for > > Windows so should zip? > > PDO is not core on windows? I do not understand what you say here. > > --Pierre >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

Andi Gutmans

20 years ago
I personally don't think it's *that* useful to have an abstraction on top of archives and in any case, it doesn't make sense for this request to come up now. If you'd like something like that, then I suggest to apply for a PECL account and work on an extension that implments it. As to having ZipArchive in the default distro. I don't think it'd hurt as long as Pierre is confident that the APIs are stable. I was sure they were but I didn't quite understand one of his last emails. Andi

Ron Korving

20 years ago
Well, if they all implement some common interface, that would really be an improvement too. And I guess in that case there'd be GZipArchive, ZipArchive, RarArchive, ... classes. People have a choice then; use the specific format of their choice and have all the extras it comes with, or go for a universal approach and use the common API as defined in the interface. Still, I think options like speed/compression factor is applicable to all or most archive formats. I don't see much feature difference among formats, only in the libraries they offer perhaps (honestly, I wouldn't really know). The only difference I can think of is that gzip doesn't seem to provide a means for compression multiple files (without resorting to tar, but TGZ support could of course be developed). - Ron "Pierre" <pierre.php@gmail.com> schreef in bericht news:fe05d1540607210500g734d1343rb881ba11ea93bba9@mail.gmail.com...

Pierre Joye

20 years ago
On 7/21/06, Ron Korving <r.korving@xit.nl> wrote:
> Well, if they all implement some common interface, that would really be an > improvement too. And I guess in that case there'd be GZipArchive, > ZipArchive, RarArchive, ... classes. > > People have a choice then; use the specific format of their choice and have > all the extras it comes with, or go for a universal approach and use the > common API as defined in the interface.
Yes, that's why I like to stay in alpha until we are sure about the basic API.
> Still, I think options like speed/compression factor is applicable to all or > most archive formats. I don't see much feature difference among formats, > only in the libraries they offer perhaps (honestly, I wouldn't really know). > The only difference I can think of is that gzip doesn't seem to provide a > means for compression multiple files (without resorting to tar, but TGZ > support could of course be developed).
I have read and checked many archives format. That's why I prefer specific extensions with a common API naming for all simple operations. More than that, like a general archive wrapper should be done in userland, it is much more flexible and easier to change. --Pierre