On Mon, 28 Jan 2008 15:53:11 +0100, till <[EMAIL PROTECTED]> wrote: > On Jan 28, 2008 12:52 PM, Thomas Bruederli <[EMAIL PROTECTED]> wrote: >> chasd wrote: >> > >> > Do the devs want to get out of RC stage to a 0.1 release before >> > concentrating on GoPHP5 ? >> >> Right. The 0.1 version will still run on PHP4 but right after the > release >> we'll drop support for PHP4 in SVN and all upcoming releases. > > We are merging all changes from 0.1rc1, 0.1rc2 and trunk into > devel-vnext right now. Tomasz comitted already a lot, and I am at it > as I write this email (which is a contradiction in itself, but you > know what I mean). > > So how many more mergers of 0.1-versions do we need? > I'd say we throw out a 0.1 ASAP then. :-) > > Thoughts?
Yes, I have one that might be of interest... Following is an announcement from the Author of the pecl-phar PHP extension I referenced in a thread related to saving all attachments in archived form. *** WARNING *** WARNING *** Windows users, beware, the Z word is used abundantly throughout the announcement. ;) Announcement: I have been working hard on pecl/phar to address several issues raised last May when it was first mentioned on the list, and would like to summarize where phar stands today with regards to those criticisms: Criticisms: * non-standard file format * limited introspection * no support for web-based applications * by default, phar archives require the phar extension to run * massive modification of php applications required to run them as a phar archive * no caching of phar files in opcode caches * has write support in the extension Current status of phar addresses most of these criticisms: * full read/write support for tar and zip file formats plus original phar file format * introspection of phar-based archives is available via the "phar.phar" command-line tool, and all standard tar/zip tools can introspect tar and zip files * web-based phar archives has been completed, 1 line of code is needed to enable the web front controller. Concept proved by running phpMyAdmin from its original tarball without code changes * default stub for phar-based archives allows standard PHP applications to run from a phar archive without the phar extension being present. * interception of read-based file functions and include now allows most php applications to run from a phar archive without any modification to the original code * Gopal committed code to APC that allows caching of files from stream wrappers * write support is disabled by default, and can only be enabled on the system level, this has not changed. phar is also the first PHP extension to provide full read/write support of the tar file format on windows (libarchive supports this on unix) phar implements zip support with native PHP code, enabling some features not present in ext/zip such as opendir() stream support, bzip2 compression, file permissions stored in the zip archive, and greatly improved efficiency on accessing just a few files within a large zip archive. phar also supports creating and running gzipped/bzipped tar or phar archives without requiring decompression (this is done on the fly) at the expense of the expected performance hit. Phar has no required dependencies, and optional dependencies on spl, zlib and bz2 (zlib+bz2 are obviously required for compressing/decompressing with those formats, spl is only required for fancy-pants stuff, the stream wrapper, web front controller, and other major features do not require spl) Development is still actively occurring on phar, to fix a few known issues and increase code coverage in the unit tests. The enhancements above are in CVS in the soon-to-be-released phar 2.0.0. If phar were in core, it would allow people distributing applications or libraries to bundle unpacking code or installation code inside the archive. Applications could also be designed to run right out of the phar archive for users to try them out or even for final installation using the standard tar/zip file formats. The phar file format has the advantage of not requiring the phar extension in order to run. The tar/zip file formats have the advantage that if the phar extension is not present a simple "unzip" command (or the equivalent for tar or for windows) allows easy installation. As such, I would like to ask for a second consideration of bundling phar in core, as it has a huge potential for enhancing the distribution of PHP applications. So it seems that it might now be even more worthwhile to consider support for this extension - possibly before the "big jump". /Especially/ given that it will be possible to distribute RC as a "phar" archive that can be run in a "demo" mode before commiting to an actual install! Kewl, huh? Well... you asked for thoughts. Didn't you? Now you have mine. :) --Chris H > > Cheers, > Till > _______________________________________________ > List info: http://lists.roundcube.net/dev/ ///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! . _______________________________________________ List info: http://lists.roundcube.net/dev/
