RE: Making PHPExcel available via a pear channel?

Hello guys, Just to keep the discussion alive: I think there are some discussion points that remain open: - Should PHPExcel be backwards compatible with PHP 5.x? - Should PEAR SEW project and efforts be merged into PHPExcel or vice-versa? The following are agreed and will be implemented in the future: - PHPExcel PEAR channel Perhaps offtopic: I just heard a Python port of PHPExcel is also being developed, I hope to have more news on that soon. Best regards, Maarten From: Mark Baker [mailto:mark@lange.demon.co.uk] Sent: woensdag 7 april 2010 18:46 To: Maarten Balliauw Cc: Carsten Schmitz <carsten.schmitz.hh@googlemail.com>; Daniel O'Connor; maarten; PEAR Dev; Progi1984; erik Subject: Re: Making PHPExcel available via a pear channel? On Wed, Apr 7, 2010 at 2:30 PM, Carsten Schmitz <carsten.schmitz.hh@googlemail.com> wrote: My feelings are that SEW should be deprecated. Unfortunately PEAR doesn't seem to know a deprecation procedure (at least I could not find any documentation about it). I think the only way to save this package would be to rip off the necessary core parts from PHPExcel. The problem with PHPExcel that I see are that its requirements are pretty high - like * PHP version 5.2.0 or higher * PHP extension php_zip enabled *) * PHP extension php_xml enabled * PHP extension php_gd2 enabled (if not compiled in) At least for the LimeSurvey project this is the reason we are not using PHPExcel since LimeSurvey itself runs from any PHP 5.x version. I think however that the requirements could be lowered by adjusting the necessary code parts. However on my request ot the PHPExcel team about this they are not interested to change it due to performance reasons (which might be true for the ODF part of PHPExcel) - I think however that having low requirments would broaden the PHPExcel userbase alot. I don't consider the PHPExcel requirements especially high, given that the latest production release of PHP is currently 5.3.2 and 5.2 has been around since February 2007, and the php_zip extension is only required for certain features (Excel2007 and OO Calc), while php_xml and php_gd2 are used by many current packages and generally seem to be enabled by many web hosting sites. Although I will concede that many ISPs and web hosts simply don't keep up to date with upgrades; and the latest Win64 binary that I can find for PHP is 5.1.6 (I've been trying to get 64-bit WAMP stack running on my new Windows 7 machines). However, some users do claim to have PHPExcel running quite happily under PHP 5.1.6. Apparently, a PHP wrapper for the zip/unzip binaries (https://sourceforge.net/project/showfiles.php?group_id=254316) could be used instead of php_zip, although I've not tried this; and php_gd2 is also only required for certain specific features (IIRC, autosize columns) - we could probably use the older, less-accurate logic as a fallback if php_gd2 wasn't available. So I don't consider it an insurmountable problem lowering some of the requirements (with a bit of work), even dropping back to PHP 5.1.6; but taking things back to PHP 5.x might be pushing the boundaries a bit too far. There's days when I consider rewriting the whole thing in C, as a PHP extension; but that would take quite some time. The biggest problem is time. There's only three of us active in the core PHPExcel team, and a lot of work being done. Currently I'm busy with: * Cell caching to reduce the memory requirements when working with large spreadsheets - a feature that users are screaming out for at the moment (21 votes on the issue list) - hopefully this will be available for the next release * Improving the OOCalc reader and working on an OOCalc writer - another feature that many of our users are requesting with 11 votes on the issue list * Basic chart support (so far, I'm reading most chart types successfully with the Excel2007 reader), and have written a renderer factory (jpGraph is currently the only rendering engine I've written wrappers for) - again, a feature that many of our users are requesting with 29 votes on the issue list * Support for named formulae * Further improvements to the performance of the calculation engine * Finishing the Excel function set - 6 votes on the issue list * Support for Excel Forms * Looking at support for running VBA within a PHPExcel sandbox And Maarten and Erik have their own priorities. We barely have the resource for the work we're already doing Reducing the requirements for PHPExcel might broaden our user base; but I don't think it would broaden it a lot until the day when a significant portion of web developers using PHP realise that an Excel file isn't simply a CSV or HTML file with an extension of .xls That's probably a similar proportion to the number of web developers using PHP who have never heard of PEAR. I am also a little worried about Maarten saying "We can setup a new PEAR package _somewhere_ that contains PHPExcel.", too. There seems to be no interest to really join the PEAR core - but I may be too paranoid on this. To sum it up: The PHPExcel team seems interested, but not too much - and preferably not if there is any additional work involved - I think they are passing a good chance here but that is for them to decide. I have no strong opinions on PHPExcel joining the PEAR core one way or the other. The main benefit would be to provide a single spreadsheet reader/writer capable of handling a wider range of spreadsheet formats than the current PEAR packages (I thought Spreadsheet_Excel_Reader was a PEAR package, but I can't find it in the PEAR repository). The drawback is the extra work in regressing PHPExcel to PHP 5.x without degrading features or performance. There's also the dependency on the OLE package (under a PHP licence rather than LGPL): that should be maintained separately, yet it's an integral component of PHPExcel; and two other packages (Structures_DataGrid and Structures_DataGrid_Renderer_XLS) are dependent on Spreadsheet_Excel_Writer. Replacing SEW with PHPExcel would have a knock-on affect on those two packages, although I don't think either is actively maintained. --- Mark Baker