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" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > Hello, > > On 7/21/06, Ron Korving <[EMAIL PROTECTED]> 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
