Re: [PHP-DEV] [RFC] Starting 5.3
Hi Lester, Milan, On Wed, Jun 25, 2008 at 7:35 AM, Lester Caine [EMAIL PROTECTED] wrote: Not a lot of use as it does not give details of how to JOIN php.internals.win I sent the email to subscribe, but the commands are the same for all php lists: list-name[EMAIL PROTECTED] or list-name[EMAIL PROTECTED] to get a list of commands (afair :) which is where Milan has been directed. Milan - bare in mind that the remaining bug listed for php_interbase is actually a linux one rather than windows, and most of the stuff currently being asked for has to be done on the raw code, so compiling also in windows comes later - since I know you are happier in linux anyway - just like I am in BORLAND windows land ;) Yes :) The primary goal is to get bug(s) fixed, code reviewed and the windows binaries tested. If you can also help to build the libraries on Windows then even better, but it is not a requirement (now or later). Thanks both for your efforts :) 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
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre Joye wrote: Hi Lester, Milan, On Wed, Jun 25, 2008 at 7:35 AM, Lester Caine [EMAIL PROTECTED] wrote: Not a lot of use as it does not give details of how to JOIN php.internals.win I sent the email to subscribe, but the commands are the same for all php lists: list-name[EMAIL PROTECTED] list-name[EMAIL PROTECTED] to get a list of commands (afair :) Just to clarify here since list-name is a little confusing. The list we are talking about is 'internals.win' when used with lists.php.net and not 'php.internals.win' as used in news.php.net or 'php-internals.win' as suggested by http://www.php.net/mailing-lists.php ( bottom - [EMAIL PROTECTED] ) I only comment because it took me a while to work out the correct path - since I had used http://www.php.net/mailing-lists.php to access internals. To tidy things up, it would be nice to see internals.win on the Internals Mailing Lists section ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Ryan Panning wrote: Are you looking for this? http://news.php.net/ Been there. Don't see any way to subscribe to internals-win, so I can post to it. Or am I missing something? Thanks, -- Milan Babuskov http://www.guacosoft.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre Joye wrote: You don't have to be a windows pro as long as you can test it on windows. The main problem now is that we had no maintainer to take care of the bugs (there is bugs), to valid a release (sources or binary), etc. Are you (still) interested? :) Yes. I'll report back when I get a working PHP build on Windows, and then someone could tell me what needs to be done exactly to get going. Thanks, -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi, Stanislav Malyshev wrote: In general, building PHP on windows should be as easy as on Unix, not requiring any special knowledge of the tools, meaning: 1. Get environment with MSVC set up 2. Get external libraries (recommended to put them in same upper-level dir as php checkout) 3. Run buildconf 4. Run cscript configure.js --options 5. Run nmake When I run nmake, it has a line that starts with instead of some command name. Looking at the configure.js script, it seems that it cannot find something called mc.exe on my system (no wonder since I don't have it), but it goes forward happily without any errors. I managed to learn little about mc.exe using Google. It's some kind of Message Compiler by Microsoft. Any idea what do I need to install to get mc.exe? It may seem that MSVC install is broken, but I can build wxWidgets and FlameRobin with it without any problems. I have MSVC 9 Express Edition. If something doesn't work along the way, most probably some library is missing or wrong version, etc. There's now dedicated windows list [EMAIL PROTECTED], which might be a better place for discussing it, but in any case description of the error message would help. Ok, thanks. -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Rob Richards wrote: Moving this to the windows list. I'm having problems to post on it. Care to forward? Make sure you are using the Visual Studio command prompt as it will setup your env for you (all the paths, etc...). I am. As I wrote, I can compile wxWidgets and FlameRobin without any problems. Maybe I was not clear enough: When I run nmake, it has a line that starts with instead of some command name. Looking at the configure.js script, it seems that it cannot find something called mc.exe on my system (no wonder since I don't have it I do not have mc.exe on my system. I did search on the hard disk to make sure. I managed to learn little about mc.exe using Google. It's some kind of Message Compiler by Microsoft. Any idea what do I need to install to get mc.exe? This is the question I'd really like to have an answer to. Not some 'usual' answer from the FAQ. Is the person that wrote/maintains configure.js script available for contact on this list? It may seem that MSVC install is broken, but I can build wxWidgets and FlameRobin with it without any problems. I have MSVC 9 Express Edition. Thanks, -- Milan Babuskov http://home.gna.org/vodovod -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Rob Richards wrote: Moving this to the windows list. I'm having problems to post on it via newsgroup interface, and I don't know how to subscribe to the mailing list, since it is not listed here: http://www.php.net/mailing-lists.php Is there a way to contact someone to add it? Thanks, -- Milan Babuskov http://home.gna.org/vodovod -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Milan Babuskov wrote: Rob Richards wrote: Moving this to the windows list. I'm having problems to post on it via newsgroup interface, and I don't know how to subscribe to the mailing list, since it is not listed here: http://www.php.net/mailing-lists.php Is there a way to contact someone to add it? Thanks, Are you looking for this? http://news.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Ryan Panning wrote: Milan Babuskov wrote: Rob Richards wrote: Moving this to the windows list. I'm having problems to post on it via newsgroup interface, and I don't know how to subscribe to the mailing list, since it is not listed here: http://www.php.net/mailing-lists.php Is there a way to contact someone to add it? Thanks, Are you looking for this? http://news.php.net/ Not a lot of use as it does not give details of how to JOIN php.internals.win which is where Milan has been directed. Milan - bare in mind that the remaining bug listed for php_interbase is actually a linux one rather than windows, and most of the stuff currently being asked for has to be done on the raw code, so compiling also in windows comes later - since I know you are happier in linux anyway - just like I am in BORLAND windows land ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lukas Kahwe Smith wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. Hi, sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. We have a working 'interbase' extenstion that does all the job, and does it well. I see that it might get moved to PECL or it might not, however, it is going to be working for a long time. Current PHP+Firebird users just don't feel that they need PDO. It could be used for new application development, but you'll hardly find a novice PHP user that is also willing to start hacking into PHP source code in parallel. Existing users are simply happy with pure ibase_ functions and ADOdb. Now, I don't know about that 'lot of shiny new software' being written on PDO, and don't really see that Firebird users will care much. Most of that software is meant to run for ISPs, hosting, etc. services and Firebird is still not on par with MySQL in that (web hosting) environment. I use Firebird for everything, except dynamic online websites where MySQL is simply the best choice. I hope that PDO stuff is not meant to completely replace mysql_, ibase_, etc. kind of functions in some distant future. -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 23.06.2008, at 14:54, Milan Babuskov wrote: Lukas Kahwe Smith wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. We have a working 'interbase' extenstion that does all the job, and does it well. I see that it might get moved to PECL or it might not, however, it is going to be working for a long time. Current PHP +Firebird users just don't feel that they need PDO. It could be used for new application development, but you'll hardly find a novice PHP user that is also willing to start hacking into PHP source code in parallel. Existing users are simply happy with pure ibase_ functions and ADOdb. Now, I don't know about that 'lot of shiny new software' being written on PDO, and don't really see that Firebird users will care much. Most of that software is meant to run for ISPs, hosting, etc. services and Firebird is still not on par with MySQL in that (web hosting) environment. I use Firebird for everything, except dynamic online websites where MySQL is simply the best choice. Its not only shiny software, its pretty much all of the standard libs people are developing. So even if you use PHP+Firebird for other stuff you will probably be unhappy that you cannot really use any of the database enabled libs in ezc and ZF. The same will probably be true for PEAR2 etc. I hope that PDO stuff is not meant to completely replace mysql_, ibase_, etc. kind of functions in some distant future. It does not seem like its going to happen in the immediate future (aka PHP 6.0) unless we will that we have nobody to contact in case of bugs and more importantly that ensures that we are aware of security issues. So for now it would be sufficient someone steps up and takes over the maintainer role for the ibase extension. This would entail doing the standard maintenance stuff like updating to the new parameter parsing API. It would also entail proactively addressing security issues. Obviously for PHP 6.0 we do need someone to update things for full unicode support eventually as well. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, Jun 23, 2008 at 2:54 PM, Milan Babuskov [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. Hi, sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. How should we understand that? Too small to actually take care of it? With the risk to repeat myself, the goal is to have a long term working extension with maintainer(s). An extension without maintainers, especially DB related extensions (or service specific extension) will slowly die within a couple of years if nothing is done. Let forget PDO for now, that's not the point (even if a working firebird support for PDO would rock). 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
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre Joye wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. How should we understand that? Too small to actually take care of it? Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO support for Firebird. If would be great pain not to have php_interbase, and if nobody is out there willing to do it, I'd like to step up. What are the requirements for someone to become an extension maintainer? With the risk to repeat myself, the goal is to have a long term working extension with maintainer(s). An extension without maintainers, especially DB related extensions (or service specific extension) will slowly die within a couple of years if nothing is done. Let forget PDO for now, that's not the point (even if a working firebird support for PDO would rock). Ok. What do I need to become a maintainer of php_interbase? I got C/C++ skills and an very familiar with Firebird (I'm part of the team that makes FlameRobin, which is an open source cross-platform C++ admin. tool for Firebird). I have access to Linux and Windows XP. Although I prefer Linux for development, I could compile something with MSVC Express Edition if/when it's really needed. Now, when we're at it, my experience with MSVC and Windows command line tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP website has some errors (some stuff just isn't where it says it is, and it seems some steps are skipped. Also, the 'configure' script used for MSVC fails to detect that those things are missing). Where should I report such problems? (Is this list appropriate for such questions)? Thanks, -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi! Now, when we're at it, my experience with MSVC and Windows command line tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP website has some errors (some stuff just isn't where it says it is, and it seems some steps are skipped. Also, the 'configure' script used for MSVC fails to detect that those things are missing). Where should I report such problems? (Is this list appropriate for such questions)? In general, building PHP on windows should be as easy as on Unix, not requiring any special knowledge of the tools, meaning: 1. Get environment with MSVC set up 2. Get external libraries (recommended to put them in same upper-level dir as php checkout) 3. Run buildconf 4. Run cscript configure.js --options 5. Run nmake 6. Enjoy your PHP build If something doesn't work along the way, most probably some library is missing or wrong version, etc. There's now dedicated windows list [EMAIL PROTECTED], which might be a better place for discussing it, but in any case description of the error message would help. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, Jun 23, 2008 at 5:36 PM, Milan Babuskov [EMAIL PROTECTED] wrote: Pierre Joye wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. How should we understand that? Too small to actually take care of it? Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO support for Firebird. If would be great pain not to have php_interbase, and if nobody is out there willing to do it, I'd like to step up. What are the requirements for someone to become an extension maintainer? With the risk to repeat myself, the goal is to have a long term working extension with maintainer(s). An extension without maintainers, especially DB related extensions (or service specific extension) will slowly die within a couple of years if nothing is done. Let forget PDO for now, that's not the point (even if a working firebird support for PDO would rock). Ok. What do I need to become a maintainer of php_interbase? Motivation and a some free time (happiness too :) Now, when we're at it, my experience with MSVC and Windows command line tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP website has some errors (some stuff just isn't where it says it is, and it seems some steps are skipped. Also, the 'configure' script used for MSVC fails to detect that those things are missing). Where should I report such problems? (Is this list appropriate for such questions)? You don't have to be a windows pro as long as you can test it on windows. The main problem now is that we had no maintainer to take care of the bugs (there is bugs), to valid a release (sources or binary), etc. Are you (still) interested? :) -- 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
Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. From my experience Firebird users are quite regionally distributed across Brazil and Russia. But anyways, the problem is of course not that we are uninterested in Firebird, but simply that nobody with the C hacker skills has taken this over yet. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. As for PDO missing pieces for Firebird, that's also untrue. Perhaps you don't understand the PDO architecture, but PDO was designed by taking into account every database client API; it has hooks to cater for just about every conceivable way of passing data into and out of a database API. It's the firebird driver that needs work. No Wez - As far as I am concerned I need to load the non PDO driver for those areas that PDO does not support. As well as the PDO driver for the data based stuff *IF* I wanted to go down that route. But at present there is no good reason to switch. User security, Event management, Services interface functions are not data based and while some of those functions are being moved into the Firebird SQL, things like Events can not go that route. Now you may think that everything at the database end should be controlled via SQL, and that is probably the case, but as we have discussed long ago, *WE* still need ADOdb to provide the SQL abstraction so there is little incentive to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is fine and are currently working ( and ADOdbLite is the 'compact' version ). While ADOdb does support PDO, the best performance is still obtained with the raw drivers for each engine. If we are NOT working with multiple engines, then we work with the raw driver so again there is little need to spend scarce time replacing something that is working and has more facilities. So until you provide a very good reason why we need to change - it's not going to happen. BLOB and parameter handling in the raw Firebird driver are a lot more flexible and simply sending a query with an optional array of parameters is much easier than HAVING to prepare everything - especially when the engine will cache things automatically anyway. PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. One of the dream features back in the early days of PDO was a way to get a native extension connection out of PDO. Unfortunately this turned out to be impossible(?) to do :( regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Wez, one is doing this: stream-orig_path = estrdup(opened_path); the other something else: stream-open_filename = __zend_orig_filename ? __zend_orig_filename : __zend_filename; stream-open_lineno = __zend_orig_lineno ? __zend_orig_lineno : __zend_lineno; best regards marcus Wednesday, May 23, 2007, 6:38:59 AM, you wrote: On 5/4/07, Marcus Boerger [EMAIL PROTECTED] wrote: 2) Add open_filename debug info to streams What is this feature and how is it different from stream-orig_path that has been around for several releases? --Wez. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
The point you're missing is that those features all belong in the firebird driver, not in PDO itself. --Wez. On 5/23/07, Lester Caine [EMAIL PROTECTED] wrote: Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. As for PDO missing pieces for Firebird, that's also untrue. Perhaps you don't understand the PDO architecture, but PDO was designed by taking into account every database client API; it has hooks to cater for just about every conceivable way of passing data into and out of a database API. It's the firebird driver that needs work. No Wez - As far as I am concerned I need to load the non PDO driver for those areas that PDO does not support. As well as the PDO driver for the data based stuff *IF* I wanted to go down that route. But at present there is no good reason to switch. User security, Event management, Services interface functions are not data based and while some of those functions are being moved into the Firebird SQL, things like Events can not go that route. Now you may think that everything at the database end should be controlled via SQL, and that is probably the case, but as we have discussed long ago, *WE* still need ADOdb to provide the SQL abstraction so there is little incentive to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is fine and are currently working ( and ADOdbLite is the 'compact' version ). While ADOdb does support PDO, the best performance is still obtained with the raw drivers for each engine. If we are NOT working with multiple engines, then we work with the raw driver so again there is little need to spend scarce time replacing something that is working and has more facilities. So until you provide a very good reason why we need to change - it's not going to happen. BLOB and parameter handling in the raw Firebird driver are a lot more flexible and simply sending a query with an optional array of parameters is much easier than HAVING to prepare everything - especially when the engine will cache things automatically anyway. PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. --Wez. On 5/23/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: But anyways, the problem is of course not that we are uninterested in Firebird, but simply that nobody with the C hacker skills has taken this over yet. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. I would not say that on the firebird-php list Wez - one hell of a lot of people rely on it for their livelyhood. I know - I'm one of them. I don't have time to waste to move perfectly functional code from one driver to another just because others say that is what must happen. I'll stick with the driver that *IS* working, and uses the optimal method of getting SQL in and out of the engine rather than having to take a second best route. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: Wez Furlong wrote: I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. I would not say that on the firebird-php list Wez - one hell of a lot of people rely on it for their livelyhood. I know - I'm one of them. I don't have time to waste to move perfectly functional code from one driver to another just because others say that is what must happen. I'll stick with the driver that *IS* working, and uses the optimal method of getting SQL in and out of the engine rather than having to take a second best route. Lester, the point is simple. Very few things in PHP get done because someone besides the actual developer needs it. In some cases this need is created by a corporate sponsor as in the case of the oci8 driver. But you can argue all you want on this, the fact of the matter is that importance in PHP is determined by the assumption that anything important will have someone to hack on. Of course some important things might just be unlucky in this setup and Firebird seems to be hit by that. So I suggest that you go hunt on firebird-php for some people with hacking skills, that are interested in playing with PDO. That being said, you are right the native extensions are slightly faster (unless you are making heavy use of fetchAll()) and they work nice and provide more features. That beind said, a lot of shiny new software is build on top of PDO and if nobody in the Firebird community picks up the PDO driver, all the Firebird users will be left out in the cold. But again, if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/4/07, Marcus Boerger [EMAIL PROTECTED] wrote: 2) Add open_filename debug info to streams What is this feature and how is it different from stream-orig_path that has been around for several releases? --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. As for PDO missing pieces for Firebird, that's also untrue. Perhaps you don't understand the PDO architecture, but PDO was designed by taking into account every database client API; it has hooks to cater for just about every conceivable way of passing data into and out of a database API. It's the firebird driver that needs work. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : RE : [PHP-DEV] [RFC] Starting 5.3
From: Greg Beaver [mailto:[EMAIL PROTECTED] Both phar/PHP_Archive and PHK support this. The only file format that would allow this kind of shebang is the tar file format, as the first element in the file is a filename. The original design of PHP_Archive used the tar file format to take advantage of this hack. So, if we want to base our format on tar, we will have to put a file with an exotic name as first element. As, anyway, the package file cannot be written via the tar command (because of this ugly first file, and probably because we'll want the next file to be a binary/serialized file map), I don't see a big benefit there. I mean a public RCS like a CVS or SVN server. I found the PHK_Creator package and looked at it in order to review the source code. Yes, I'd like to store it on such a server. But I don't know these systems very well. I planned to put it on sourceforge but I didn't have enough time yet. This is exactly how phar/PHP_Archive works. For example: http://pear.php.net/go-pear.phar contains the complete PHP_Archive class, which will fall back to the phar extension if available. But you say in the doc that the stub can contain any code terminated by an __halt_compiler(); ? I don't understand. If a phar archive is generated by the phar extension, it does not include the PHP_Archive runtime code, right ? So, it cannot run without the phar extension installed. Am I wrong ? I am probably unclear with my argument here. After a deep review of the source code, it seems to me that PHK is basically PHP_Archive with a different file format plus a few built in extras and a separate website. In other words, at the time you started the PHK project, PHP_Archive was fully functioning (version 0.6.0, released on 2005-08-30) and was backed by the officiality of being served from PEAR, a php.net site. Rather than attempt to inject your interesting ideas for the future of PHP_Archive, you seem to have actively avoided PHP_Archive and re-invented the wheel. Actually, there is a reason, PHK was not the first step... The first step was the autoloader. When it was ready, I started thinking of a sort of jar feature for PHK. So, of course, I looked at PHP_Archive to see if I could integrate my autoloader. But, at this time (end 2005), there was not much documentation and the first tests showed that the PHP_Archive'd package checked if it was run as 'main file'. When I tried to include it, I got an error message saying that it had to be the first script to run. So, as I wanted to make library packages, I started a small project which became PHK, without 'actively avoiding' PHP_Archive. I also must say that, yes, I tend to consider that a project whose only documentation is the source code is not a good development base. Maybe it is too theoritical but, IMO, a project without any doc is not 'fully functioning' :) Now, PHP_Archive has evolved into phar and, yes, PHK provides almost every features present in phar. But, where I disagree, is when you say that it just add 'a few built in extras and a separate website'. If you look at the code, you will see that these 'few built-in extras' represent more than 80 % of the product. I think the difference here is the way we consider these 'built-in extras'. I try to consider them from a non-expert point of view, and I try to imagine what can convince and/or seduce an average user. So, by providing demo packages, building kits, and an extensive documentation, I try to solve the problems a newcomer can meet. This is the way I always work. It is not a pleasure but a way to provide something to be considered as a 'product'. You seem to under-estimate the work it needs to design and build these 'few built-in extras': one year ago, I had quite the same features you provide in PHP_Archive/phar today. But I chose to spend several hundreds more hours on the remaining 'few built-in extras'. To resume, when I read phar's doc, I see a tool to be used by people like you or me, people with a (very) good knowledge and experience in PHP, and able to build the 'glue' scripts they need. That's what you consider 'easy', because it would be easy for you. I also find it easy, but my goal with PHK is not to provide a tool that can be used by, maybe, 100 people in the world. To resume, I consider that the features I added upon phar-like bare features are more important than you think. They are at least as important as the low-level ones. Actually, when I had to determine where to stop, I decided that, for most cases, a packager does not have to explicitely use the stream wrapper. It is now the case and the stream wrapper and every underlying features can be considered as advanced features. By contast, in phar, these low-level features are... the only ones available. I hate to be the one to burst our bubble, but unicode is a killer feature and PHP 6 will be adopted en masse, so if this isn't
[PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
Hello LAUPRETRE, Tuesday, May 15, 2007, 7:12:27 PM, you wrote: From: Greg Beaver [mailto:[EMAIL PROTECTED] This is exactly how phar/PHP_Archive works. For example: http://pear.php.net/go-pear.phar contains the complete PHP_Archive class, which will fall back to the phar extension if available. But you say in the doc that the stub can contain any code terminated by an __halt_compiler(); ? I don't understand. If a phar archive is generated by the phar extension, it does not include the PHP_Archive runtime code, right ? So, it cannot run without the phar extension installed. Am I wrong Yes, noone hinders you to write PHP_Archieve into your stub when using the Phar extension. I am probably unclear with my argument here. After a deep review of the source code, it seems to me that PHK is basically PHP_Archive with a different file format plus a few built in extras and a separate website. In other words, at the time you started the PHK project, PHP_Archive was fully functioning (version 0.6.0, released on 2005-08-30) and was backed by the officiality of being served from PEAR, a php.net site. Rather than attempt to inject your interesting ideas for the future of PHP_Archive, you seem to have actively avoided PHP_Archive and re-invented the wheel. Actually, there is a reason, PHK was not the first step... The first step was the autoloader. When it was ready, I started thinking of a sort of jar feature for PHK. So, of course, I looked at PHP_Archive to see if I could integrate my autoloader. But, at this time (end 2005), there was not much documentation and the first tests showed that the PHP_Archive'd package checked if it was run as 'main file'. When I tried to include it, I got an error message saying that it had to be the first script to run. So, as I wanted to make library packages, I started a small project which became PHK, without 'actively avoiding' PHP_Archive. I also must say that, yes, I tend to consider that a project whose only documentation is the source code is not a good development base. Maybe it is too theoritical but, IMO, a project without any doc is not 'fully functioning' :) Well the limitations you encountered back then are long gone. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
Yes, noone hinders you to write PHP_Archieve into your stub when using the Phar extension. Actually, I would say it would be better to have some minimized version which is extract-only, has all the comments stripped, etc. for inclusion in the archives. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : RE : [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote:
Yes, noone hinders you to write PHP_Archieve into your stub when using
the Phar extension.
Actually, I would say it would be better to have some minimized
version which is extract-only, has all the comments stripped, etc. for
inclusion in the archives.
This is extremely easy to do with phar, perhaps this is best done
through documentation? Such a script would be extremely short and would
definitely be cut-and-pasteable, for instance:
?php
$here = dirname(__FILE__) . DIRECTORY_SEPARATOR . basename(__FILE__,
'.phar');
mkdir($here);
foreach (new RecursiveIteratorIterator(
new RecursiveDirectoryIterator('phar://' . __FILE__)) as $path
= $unused) {
$newpath = $here . DIRECTORY_SEPARATOR . str_replace('/',
DIRECTORY_SEPARATOR,
str_replace('phar://' . __FILE__ . '/', '', $path));
if (!file_exists(dirname($newpath))) mkdir(dirname($newpath), 0664,
true);
copy($path, $newpath);
}
__HALT_COMPILER();
Setting the stub is really easy:
$phar-setStub($code);
where $code contains the stuff above as a string, or as an open file
pointer to the file stub. The minimal script might want to instead use
$argv[1] or even display a web form, depending on the context - this is
the primary reason we didn't hard-code a massive stub. By default, the
stub created by making a phar is designed for a minimal non-extract
library, but phar is designed with enough flexibility that is is not
just easy but remarkably simple to do extremely complex stuff with the
stub or with the contents. In fact, it is much easier than either
PHP_Archive or PHK, and this is a direct result of features that are not
possible with a userspace stream. One can argue over their utility but
the original reason behind making PHP_Archive into an extension is no
longer the only reason.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3
From: Greg Beaver [mailto:[EMAIL PROTECTED] With all due respect, this is a rather severe exaggeration of PHK's talents. PHK does *not* use a standardized file format like ZIP, and the format is undocumented as of last Friday when I read all of the docs at your site. Right. As for phar, I didn't find a format to support every features I wanted. You're right, it does not solve EVERY issues people raised about phar :) The main problem, as you know, is to find a format which allows the archive file to be included as a PHP script file. And I also wanted to be able to set an 'interpreter' line (a line starting with '#!') at the beginning of the file. If somebody knows a format which supports that, please tell me. PHK source code is not easy to find (is it even publicly available?) Wrong. PHK source code is contained in the PHK_Creator package (which inserts it in every package it creates). Either you extract it from the PHK_Creator PHK file, or you download the PHK_Creator building kit: it is quite the same but in tar format, with the Makefile and PSF file used to create the creator package. PHK source code does not adhere to any coding standard I've ever seen before. Right. I am currently modifying it to become conform to PEAR standards. PHP_Archive (the equivalent to PHK) is only needed to create the .phar archives, just as PHK is needed to create PHK archives (no difference - external tool needed) but in both cases nothing is needed to run the resulting archives. I don't understand. In order to be able to include a phar archive, the phar stream wrapper must have been defined previously, either by PHP_Archive or by the PHAR extension. When you include a PHK archive, you just need PHP version 5.1 or more, as the runtime code is included in the archive. And, when the accelerator will be available, it will be the same : the embedded runtime code will detect the optional accelerator and use it transparently. PHK is developed by one developer without the benefit of community oversight, or any evidence of interest in community-based open source development at all. This is unfair. I tried to get interest from PHP core developers from the beginning, 18 months ago. The only replies I got were rude ones, 'what's wrong with phar ?' style. How can you speak of 'community oversight' when I COULD NOT get any interest from the community! From the beginning, everything is available on my website, there are now more than 50 pages of documentation about PHK. I also registered the project on freshmeat, sourceforge, and hotscripts. What can I do more ? You want to know me personnally ? I'd love to go to PHP conferences but I can't afford. I am living in France, and even european events are too expensive, considering hotel and travel. Please understand that I am an independant contractor, without a company to pay for it. Something else: I proposed PHK as a conference subject for almost every PHP events since 12 months. In most cases, I didn't even get any reply. In France, it was refused and people even told me that they were looking for 'serious' subjects... Now, I don't propose it any more as it is too frustrating. It helped me to understand that the PHP core community is a very closed group of 15-20 people. Of course,it is important to know each other, but you should be more open to ideas coming from the outside. Every time I submitted something on the mailing list, the rare times where I got a reply, it was just to destroy my ideas. And I am not the only one, when I see the tone of some messages, I am really ashamed. PHP needs fresh ideas. Too many people reply things like 'I am not presonnally interested by this feature, so nobody is', as in this thread... As an 'evidence of interest in community-based open source development', I also proposed PHK to the Zend Framework project, building the packages, integrating the unit tests, writing an RFC to demonstrate the benefits it can bring. Yes, it is 'developed by one developer', but it is not a choice, believe me. If somebody wants to help with the accelerator extension, he is welcome ! I don't take this as an argument, but PHAR has been developed by 3 developers, now 2 active, with very little community interest and oversight... The advantages PHK possesses are 1) snazzier looking website 2) integrated introspection (which cannot be disabled at packaging time no?) PHP_Archive does not require introspection but assumes the programmer would write it - something that would be a wonderful addon. No, the introspection code cannot be disabled at packaging time, as it must remain an integral part of the package and a standard feature. 3) built in front controller. A front controller is easy enough to write I did not consider it necessary to enable one by default, but this is not a bad idea as an optional accessory for beginning users. I don't see it as an 'optional'
[PHP-DEV] Re: RE : [PHP-DEV] [RFC] Starting 5.3
LAUPRETRE François (P) wrote: From: Greg Beaver [mailto:[EMAIL PROTECTED] With all due respect, this is a rather severe exaggeration of PHK's talents. PHK does *not* use a standardized file format like ZIP, and the format is undocumented as of last Friday when I read all of the docs at your site. Right. As for phar, I didn't find a format to support every features I wanted. You're right, it does not solve EVERY issues people raised about phar :) The main problem, as you know, is to find a format which allows the archive file to be included as a PHP script file. And I also wanted to be able to set an 'interpreter' line (a line starting with '#!') at the beginning of the file. If somebody knows a format which supports that, please tell me. Both phar/PHP_Archive and PHK support this. The only file format that would allow this kind of shebang is the tar file format, as the first element in the file is a filename. The original design of PHP_Archive used the tar file format to take advantage of this hack. PHK source code is not easy to find (is it even publicly available?) Wrong. PHK source code is contained in the PHK_Creator package (which inserts it in every package it creates). Either you extract it from the PHK_Creator PHK file, or you download the PHK_Creator building kit: it is quite the same but in tar format, with the Makefile and PSF file used to create the creator package. I mean a public RCS like a CVS or SVN server. I found the PHK_Creator package and looked at it in order to review the source code. PHP_Archive (the equivalent to PHK) is only needed to create the .phar archives, just as PHK is needed to create PHK archives (no difference - external tool needed) but in both cases nothing is needed to run the resulting archives. I don't understand. In order to be able to include a phar archive, the phar stream wrapper must have been defined previously, either by PHP_Archive or by the PHAR extension. When you include a PHK archive, you just need PHP version 5.1 or more, as the runtime code is included in the archive. And, when the accelerator will be available, it will be the same : the embedded runtime code will detect the optional accelerator and use it transparently. This is exactly how phar/PHP_Archive works. For example: http://pear.php.net/go-pear.phar contains the complete PHP_Archive class, which will fall back to the phar extension if available. PHK is developed by one developer without the benefit of community oversight, or any evidence of interest in community-based open source development at all. This is unfair. I tried to get interest from PHP core developers from the beginning, 18 months ago. The only replies I got were rude ones, 'what's wrong with phar ?' style. I am probably unclear with my argument here. After a deep review of the source code, it seems to me that PHK is basically PHP_Archive with a different file format plus a few built in extras and a separate website. In other words, at the time you started the PHK project, PHP_Archive was fully functioning (version 0.6.0, released on 2005-08-30) and was backed by the officiality of being served from PEAR, a php.net site. Rather than attempt to inject your interesting ideas for the future of PHP_Archive, you seem to have actively avoided PHP_Archive and re-invented the wheel. I don't take this as an argument, but PHAR has been developed by 3 developers, now 2 active, with very little community interest and oversight... On the contrary, several developers have been active in testing the extension and in reporting bugs/design flaws from the beginning. Most of the activity has been informally through IRC or through email, so this is understandably not as visible to you as it would otherwise have been. And, if they don't, unfortunately, it will be one more reason not to switch to PHP 6 :) I hate to be the one to burst our bubble, but unicode is a killer feature and PHP 6 will be adopted en masse, so if this isn't changed, it will simply mean the death of userspace stream wrappers for anything but custom projects. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : [PHP-DEV] [RFC] Starting 5.3
On 5/14/07, Greg Beaver [EMAIL PROTECTED] wrote: And, if they don't, unfortunately, it will be one more reason not to switch to PHP 6 :) It has been several times by several developers that this specific problem will/must be fixed, no matter if whateveryoulike will be bundled or not. It would nice if you (=1) stop to use it as an argument. Secondly, as you nicely said in this mail, any php archive can be executed without any deps (for 6.x, refer to the previous paragraph ). It was always the case (see FUDForum installer as prior art) and will always be the case (I'm pretty sure we will see a good dozen different implementations in the next months, in the pure tradition of my wheel rolls better than yours). By the way, arguing endlessly about the superiority of your respective rounded rectangles will not help a single second to take the right decision (which is yet negative afaics). However answering the open questions will. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : [PHP-DEV] [RFC] Starting 5.3
And, if they don't, unfortunately, it will be one more reason not to switch to PHP 6 :) I hate to be the one to burst our bubble, but unicode is a killer feature and PHP 6 will be adopted en masse, so if this isn't changed, it will simply mean the death of userspace stream wrappers for anything but custom projects. You are being optimistic. If PHP6 breaks code, it won't be adopted or adoption will be slow. RFC 2044 was written in October 1996. 10.5 years ago. Unicode v.1.0 standard was written in 1992. People still use other charsets. Outlook Express defaults to ISO-8859-x or CP125x charsets. Mozilla defaults to iso-8859-1. Stock Eudora works only with ISO-8859-1. Lots of sites are written with assumption that client defaults to cp125x or iso-8859-x. IDN is a killer feature and people continue using old ASCII only DNS names. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RE : [PHP-DEV] [RFC] Starting 5.3
LAUPRETRE François (P) wrote: From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] ...and phar is the best candidate I know for this. I'd say the only one NO, there is an alternate PHP package format. It solves every issues you rose about phar (including the direct url access to a virtual file). Its name is PHK and it is available at http://phk.tekwire.net. The site includes an extensive documentation and several demo packages, including PHPUnit, the Zend Framework, The ZF documentation, Smarty,... Please also note that a PHK pakage embeds everything needed to manage its internal subfiles, avoiding the need for a an external (pear?) tool. With all due respect, this is a rather severe exaggeration of PHK's talents. PHK does *not* use a standardized file format like ZIP, and the format is undocumented as of last Friday when I read all of the docs at your site. PHK source code is not easy to find (is it even publicly available?) PHK source code does not adhere to any coding standard I've ever seen before. PHP_Archive (the equivalent to PHK) is only needed to create the .phar archives, just as PHK is needed to create PHK archives (no difference - external tool needed) but in both cases nothing is needed to run the resulting archives. PHK is developed by one developer without the benefit of community oversight, or any evidence of interest in community-based open source development at all. The advantages PHK possesses are 1) snazzier looking website 2) integrated introspection (which cannot be disabled at packaging time no?) PHP_Archive does not require introspection but assumes the programmer would write it - something that would be a wonderful addon. 3) built in front controller. A front controller is easy enough to write I did not consider it necessary to enable one by default, but this is not a bad idea as an optional accessory for beginning users. 4) interesting idea of mounting archives (not quite sure if this requires the use of PHK_Util to load archives or works with native require_once? 5) easy docs on how to use it The phar extension provides #5 at a more complete level than PHK (i.e. file format is documented) at http://www.php.net/phar PHK does not solve the issues that PHP_Archive has which is it too will stop working in PHP 6. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Am Freitag, 4. Mai 2007 20:16 schrieb Edin Kadribasic: I think that Phar is going to be useful only if its universally available in the PHP installs, and I think that would a good thing for PHP. Edin, why do you bind the usefulness to the number of installs? That sounds more like enthusiam than an elaborated argument.:) Best Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Am Freitag, 4. Mai 2007 21:24 schrieb Ilia Alshanetsky: It sounds like the merits of having phar is would only be apparent after it is included in the core and everyone starts using it because of that. This won't happen simply because most software producers can't rely on extensions that are only available in version X. I don't understand the last senctence, to be true. But I have another good reason which will hinder that: Phars support compression using gzip if the zlib extension is present, and using bzip2 if the bz2 extension is present. As far as I know that are two different compression formats!? So you need to handle three types of archives. Are you going to provide three versions of every archive? Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Am Freitag, 4. Mai 2007 20:09 schrieb Antony Dovgal: not the other way round. If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. That is good point. If PECL extensions could be integrated into php by just set --enable-extensionX while compiling the php distribution. That would be a major facilitation. php will then automatically download and intergrate the extension source into the source tree before 'make' will compile everything. With user interaction, of course! - But maybe that's enthusiasm too. Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Oliver, we are discussing situations where make is no option here. Everone that hasmake as an option and all tools available can always easily do: pecl install extension Without the pear or pecl commandyou can also simply download the pecl extension package and do the following: tar -x package phpize ./configure make make install Also still easy enough. However this is in many situation not possible at all. For once it is impossible if you are using a shared server. best regards masrcus Thursday, May 10, 2007, 10:29:08 PM, you wrote: Am Freitag, 4. Mai 2007 20:09 schrieb Antony Dovgal: not the other way round. If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. That is good point. If PECL extensions could be integrated into php by just set --enable-extensionX while compiling the php distribution. That would be a major facilitation. php will then automatically download and intergrate the extension source into the source tree before 'make' will compile everything. With user interaction, of course! - But maybe that's enthusiasm too. Regards, Oliver Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
That is good point. If PECL extensions could be integrated into php by just set --enable-extensionX while compiling the php distribution. That would be a Maybe in more generic form like --enable-pecl=EXTENSION or --enable-pecl=/path/to/file.tgz but if autoconf magicians among us could pull this off it might be nice shortcut. Automatic downloading can be tricky, but the rest should be relatively easy... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/10/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: That is good point. If PECL extensions could be integrated into php by just set --enable-extensionX while compiling the php distribution. That would be a Maybe in more generic form like --enable-pecl=EXTENSION or --enable-pecl=/path/to/file.tgz but if autoconf magicians among us could pull this off it might be nice shortcut. Automatic downloading can be tricky, but the rest should be relatively easy... Yeah I was also thinking about something like --enable-pecl-extensionName example: ./configure --enable-pecl-phar --enable-pecl-geoip ... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Am Donnerstag, 10. Mai 2007 22:47 schrieb Marcus Boerger: we are discussing situations where make is no option here. However this is in many situation not possible at all. For once it is impossible if you are using a shared server. I know, If I follow that part of the discussion, it's about .php files (apps) not pecl, right. Regards, Oliver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/9/07, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Pierre, Tuesday, May 8, 2007, 10:59:08 PM, you wrote: On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? Given that either PHP_Archive or pecl/phar are not required to execute a phar, I really don't see the point here. There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to a situation where practically every phar would have to include the PHP_Archive.Which would be suboptimal. Well, as I can understand your point, it is not really a problem. pear.phar is bundled and used by hundred of users and developers to install pear and it includes the php code. That does not answer my question, what's the gain of using an extension instead of the php implementation (to execute it)? (please don't answer me to try it myself :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] ...and phar is the best candidate I know for this. I'd say the only one NO, there is an alternate PHP package format. It solves every issues you rose about phar (including the direct url access to a virtual file). Its name is PHK and it is available at http://phk.tekwire.net. The site includes an extensive documentation and several demo packages, including PHPUnit, the Zend Framework, The ZF documentation, Smarty,... Please also note that a PHK pakage embeds everything needed to manage its internal subfiles, avoiding the need for a an external (pear?) tool. I proposed this tool some months ago and I was severely kicked out by Marcus and friends because they took it as an attack against phar... It is not, it is an alternative. And, after reading all your reactions to his proposal of integrating phar into PHP core, I pretend that every issues you rose are solved in PHK. I didn't want to talk about it anymore on this list because nobody seemed to be interested in the subject but, as Marcus himself started it again, maybe it is time for some of you to make a comparison... And I cannot let you say that phar is the only existing package format for PHP ! Please note that, on the performance side, I am currently working on a runtime accelerator for PHK. It will be an OPTIONAL tool, which, as first tests show, will allow to reduce the overhead by at least 90 %, allowing PHK packages to run in production environments without significant performance degradation. Regards Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3
-Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. What happens we need next application using named streams? Another extension into main PHP source whose purpose is to duplicate PHP code and work around our own security model? Right. The problem is with the decision of considering every user stream as remote. As with most software, not more than 10% of PHP_Archive needed a C accelerator. And because of this decision, they had to convert everything into a C extension ! Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3
As I mentioned a few days ago (I see the thread has been very active since so not sure people will remember) is that we'll try and take a deeper look at phar and some of the issues we raised. Also looking at this in parallel makes a lot of sense. We shouldn't be married to a specific implementation but should try and evaluate better what is really an optimal solution and can we solve it well so that it's useful for the broader community (Easily toolable, works with Apache, byte-code accelerators, etc...) -Original Message- From: LAUPRETRE François (P) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 4:23 AM To: Stas Malyshev; Stefan Priebsch Cc: internals@lists.php.net Subject: [PHP-DEV] RE : [PHP-DEV] [RFC] Starting 5.3 From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] ...and phar is the best candidate I know for this. I'd say the only one NO, there is an alternate PHP package format. It solves every issues you rose about phar (including the direct url access to a virtual file). Its name is PHK and it is available at http://phk.tekwire.net. The site includes an extensive documentation and several demo packages, including PHPUnit, the Zend Framework, The ZF documentation, Smarty,... Please also note that a PHK pakage embeds everything needed to manage its internal subfiles, avoiding the need for a an external (pear?) tool. I proposed this tool some months ago and I was severely kicked out by Marcus and friends because they took it as an attack against phar... It is not, it is an alternative. And, after reading all your reactions to his proposal of integrating phar into PHP core, I pretend that every issues you rose are solved in PHK. I didn't want to talk about it anymore on this list because nobody seemed to be interested in the subject but, as Marcus himself started it again, maybe it is time for some of you to make a comparison... And I cannot let you say that phar is the only existing package format for PHP ! Please note that, on the performance side, I am currently working on a runtime accelerator for PHK. It will be an OPTIONAL tool, which, as first tests show, will allow to reduce the overhead by at least 90 %, allowing PHK packages to run in production environments without significant performance degradation. Regards Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: PHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions. I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. So why don't you come up with a different better solution then? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello internals, Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote: On 5/8/07, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 7 May 2007, Stanislav Malyshev wrote: We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? In the past we have bundeled even stuff that has not been stable or in a mature state. And I have not seen a single reason against it. The only one close so far was that PHARs cannot be handled with your favorite Winzip or whatever you are using. Guess what, I have PHP installed and last time I checked PHP worked nearly perfectly. And last time I had to deal with JARs I did not have the slightest advantage of having it be a ZIP file. Just because in all those Java formats you have to provide specific files in a very specific format with very specific content. And this is the absolute opposite of the flexibility we aim for with Phar. Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem And to read zip files (upload, ftp, remote data). I think each of us has had to deal with zip data (read or write) more than once. It is a mainstream need. Or if you mean that phar is not a mainstream problem then I agree. But I don't really see the point to compare both, they are too completely different extension (general purpose and developer/packager extension). I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). However once this package got a wider audience and users base, I don't have real objections to do not bundle it even if I still think that phar is a packager tool and have little to do with the mainstream needs. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 12:36 PM, Marcus Boerger wrote: The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? And I have not seen a single reason against it. I have not seen a single reason FOR it either. The only half-valid reason is that phars will stop working in PHP6 because of the streams breakage. But that's definitely the reason to fix streams, otherwise we'll have to include each every extension using custom streams. Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 12:36 PM, Marcus Boerger wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem and b) we should not eventhink of turning it into a JAR and hack around PHP all over. Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Please, Marcus don't mix your personal feelings and the question we're discussing here. PECL/zip has nothing to do with PEAR/phar and it does not matter how mainstream is it. *Unfortunately* it's already there, so it's too late to discuss whether it was good or bad decision. And referring to other extensions (they did it, why can't I do it) is just childish. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Pierre, Tuesday, May 8, 2007, 10:58:19 AM, you wrote: On 5/8/07, Marcus Boerger [EMAIL PROTECTED] wrote: Now adding Pecl/Zip was a clever idea as it allows an easy way to compress stuff on the fly for sites that offer downloads. However this is a) far far away from a mainstream problem And to read zip files (upload, ftp, remote data). I think each of us has had to deal with zip data (read or write) more than once. It is a mainstream need. Or if you mean that phar is not a mainstream problem then I agree. But I don't really see the point to compare both, they are too completely different extension (general purpose and developer/packager extension). I hoped to make clear that even all of them are package extensions at least to me they severe a different purpose. Especially I wanted to point out that we should not make any of them executeable like JARs. I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). We do not need to create 5.3 to bundle it. And well if you design something and test it thoroully you can mark even the first public release as stable. We've even put phar to gcov.php.net prior to releasing it to prevent memleaks and ensure a pretty high quality. After that we waited ffor another half year and only then after still being sure it works (by checking that it worked for us) we released it. However once this package got a wider audience and users base, I don't have real objections to do not bundle it even if I still think that phar is a packager tool and have little to do with the mainstream needs. In this case the audience is the PHP_Archive audience as well. It is one of the things PECL was designed for. Develop something in PHP and the turn it into a PHP extension. --Pierre Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Antony, Tuesday, May 8, 2007, 10:59:28 AM, you wrote: On 05/08/2007 12:36 PM, Marcus Boerger wrote: The point is to make local URL wrappers working, not only phar://. Stanislav and Tony have a point, writing a custom extension to fix a problem that we introduced is a bad idea and does not solve the problem for anyone else but phar. If phar will be bundled or not does not matter, this problem has to be solved anyway. Right Pierre, as you said, this is a different thing that might have to be addressed anyway. However phar is a real life thing that needs to be working. Besides, Phar is neither a custom extension - at least i do not see either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). Andwewould have to decide on a sane pugable API. One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. Meaning that none of those arguemts speaks against Phar. If feel the need to misinterpret these arguments than i am sorry. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/08/2007 01:17 PM, Marcus Boerger wrote: But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Please correct me if I'm wrong: phars do work without PECL/phar, don't they? Then why in hell do we need PECL/phar in the core? (except for that streams problem) Because it's faster than PHP_Archive? I don't really care if PEAR install takes 5 seconds or 4 seconds, I can wait one more second once in a month. If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. The only tool required is autoconf (2.13 is recommended, other versions are supported too). All the other tools are required by PHP itself. You don't need to be an experienced admin to install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it.. (Btw, Ilia recently proposed to create packages with pre-built configure, so even the autoconf requirement would go). Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). I'm not sure I understand what you're talking about. We never provided debug binary builds and I see no reasons to do it. Andwewould have to decide on a sane pugable API. Okay, let's do it. We have a nice chance to break everything we can - it's PHP6 anyway =) I'd really like to hear your thoughts on improving the API. Want to make a separate thread? One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. This IS the discussion board. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. Ok, so let me summarize it: to leave PECL/phar in PECL you need a new pluggable API, and to create the API you need a discussion board, but even having it you would not discuss the API because nobody respects TODOs. Did I miss something? In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. PECL/json, PECL/zip and the others were/are stable too. That doesn't mean there are no bugs we don't know of. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
So why don't you come up with a different better solution then? Not breaking streams in php 6? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. So from now on, every time we would want to user stream we'd have to do C extension and all user stream functionality in PHP is just useless? And all that for some weird reincarnation on safe mode again? I don't know how it sounds for you, but form be it sounds really broken way to do things - throwing perfectly good and working userspace streams because of pseudo-security configurations. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
either Greg or me as PHP customers. Nor was Phar designed to solve that particular issue alone. It was designed to deliver a stable and fast implementation of PHP_Archive that can be bundled into PHP as a C extension. That's fine, the question is why exactly we need fast implementation of PHP_Archive that can be bundled into PHP as a C extension. I see only one reason - to run php code in production out of phar, and I don't think it's a good idea. Any other reasons? Guys what I don't understand is why some few people bicker around Phar so much, just because they have no private use for it? In the Maybe if you actually tried to read the arguments instead of dismissing them as bickering you'd actually see why. I brought forward a number of reasons and neither of them was it's of no private use for me. You can do better than this, really. past we have bundeled even stuff that has not been stable or in a mature state. So we should do that more and more, right? More unstable stuff with potential for abuse is great for PHP, isn't it? And I have not seen a single reason against it. The only one close Maybe you should actually read my emails? last time I checked PHP worked nearly perfectly. And last time I had to deal with JARs I did not have the slightest advantage of having it be a ZIP file. Just because in all those Java formats you have to You didn't doesn't mean nobody did. You aren't the only programmer in the universe, you know, and people behind most of the packaging formats seem strangely united in *not* inventing new package formats but reusing old ones with existing tools. I wonder why would that be? the fly packing and Phar for deployment. And if some people want to execute phars directly, then why the hell make it hard for them or even disallow that? Because it's a bad idea. And nobody disallowing that - we just refrain from promoting it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? Documentation and other code analyis tools. Database management tools. Code generation tools. Well I think the first two are more likely, code generation tools tend to be very tightly coupled with your actual application. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
When I first wrote PHP_Archive the entire point of the stub script was to handle incoming requests, just like the multitude of applications that have everything go through index.php (S9Y for an example). Using Phar with MultiViews and mod_rewrite is just same as funnelling everything through a single regular PHP script, this was one of the design goals and is a very common practice. The main difference here, is with web applications you have non-HTML resources you must also handle - this WILL incur a performance hit over serving them as a static page. But applications like S9Y, FUDForum, phpMyAdmin where the *typical* usage is not to serve a large number of users, this is usually not an issue. These techniques work just fine. - Davey Marcus Boerger wrote: Hello Andi, Friday, May 4, 2007, 9:55:23 PM, you wrote: I think phar is a nice idea but honestly haven't had enough bandwidth to check it out in more detail. Has there been some thorough analysis on the performance impact of it and whether this is the optimal recommended way for our users to distribute apps? The idea is actually very interesting but we should be pretty certain we're doing the right thing before we distribute it. We can spend some time looking at it in more detail. You guys spent a good effort in such analysis in the past. Would be very nice to hear something in that direction from you. Btw, it seems to me that because of the way Apache works for most of our users it actually won't be that useful and just act like a .tar archieve which needs to be extracted. This is unless the user implements some kind of front controller. It would really be nice if we have the 99% common Apache application use-case figured out and docuemnted before we put our PHP dev team weight behind it. Or am I completely missing some magic here? not at all. It perfectly works for includes. But i have no idea how to use it from a url directly...well you can provide some tricks. But i wouldn't recommend those. Andi -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Friday, May 04, 2007 12:44 PM To: Stas Malyshev Cc: Edin Kadribasic; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Starting 5.3 Hello Stanislav, - you don't need a tool - well php - but hey you probbaly have that tool - you can run phar archives out of the box - untouched - you can extract phar archives and run them - still untouched - you can provide phar archives that do not require a phar extension To your question is phar so important that everybody needs it in the main source. I think the above means it should. best regards marcus Friday, May 4, 2007, 9:36:22 PM, you wrote: obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. I'm personally not sure phar is that great way of distributing apps - it's yet another format not supported by standard tools and I don't really see much of an advantage to using it versus just making a package with any of the existing package formats and I see a number of disadvantages - non-standard format, hard to work with packed scripts with available filesystem tools, etc. But that's my opinion and I fully expect some people to hold exactly the opposite opinion. The question is however is phar so important that everybody needs it in the main source? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: serving them as a static page. But applications like S9Y, FUDForum, phpMyAdmin where the *typical* usage is not to serve a large number of users, this is usually not an issue. In other words, it is not meant to deploy production applications, only local-user applications. Then the question raises again - why exactly we need the module? Low-traffic occasional-use apps do not need top performance, and PHP module should be just enough for them. No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see php.net or yahoo! using phar any time soon, but any site not currently leveraging a bytecode cache would certainly be included. This is the MAJORITY of PHP deployment. Something akin in traffic and use as bugs.php.net could use phar without any detriment (though not knowing what else that particular machine is used for, I wouldn't say to move bugs.php.net itself over, just giving an idea of size and scale :) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? Given that either PHP_Archive or pecl/phar are not required to execute a phar, I really don't see the point here. Now, from a performence point of view, how faster (or less slow) is the extension in comparison to the user land stream implementation? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator, php_lexergenerator should I continue? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre wrote: I'm in general in favour of phar but I don't think we should start 5.3 for it. I don't think either that it is stable enough to be bundled. I doubt it is possible to have a stable package in only three public releases (even the first public release was already marked stable). FYI, there were two beta releases prior to 1.0.0 stable, with months in between the releases for testing, plus the test coverage at gcov is quite good. Not that these are fantastic indicators of stability as we all know but it is something :) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Gregory Beaver wrote: Stanislav Malyshev wrote: I think it is a good reason. There are plenty of tool-like PHP applications. Not having to install these, but just be able to I know one - PEAR. And it's kinds special because it's library installer. What others are there? phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator, php_lexergenerator should I continue? I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Antony, it make it much harder as you would need to load PHP_Archive before you can do anything else with them. It would mean you cannot easily execute them unless they contain PHP_Archive themselves best regards marcus Tuesday, May 8, 2007, 11:39:32 AM, you wrote: On 05/08/2007 01:17 PM, Marcus Boerger wrote: But the main argument for including it that it's going to solve the newly created problem. I.e. PEAR and all the other phar packages work perfectly fine without it. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. Please correct me if I'm wrong: phars do work without PECL/phar, don't they? Then why in hell do we need PECL/phar in the core? (except for that streams problem) Because it's faster than PHP_Archive? I don't really care if PEAR install takes 5 seconds or 4 seconds, I can wait one more second once in a month. If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR. I'm against including new PECL stuff in the core and I've repeated that several times already. Things should go the other way round - from the core to PECL. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. The only tool required is autoconf (2.13 is recommended, other versions are supported too). All the other tools are required by PHP itself. You don't need to be an experienced admin to install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it.. (Btw, Ilia recently proposed to create packages with pre-built configure, so even the autoconf requirement would go). Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). I'm not sure I understand what you're talking about. We never provided debug binary builds and I see no reasons to do it. Andwewould have to decide on a sane pugable API. Okay, let's do it. We have a nice chance to break everything we can - it's PHP6 anyway =) I'd really like to hear your thoughts on improving the API. Want to make a separate thread? One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. This IS the discussion board. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. Ok, so let me summarize it: to leave PECL/phar in PECL you need a new pluggable API, and to create the API you need a discussion board, but even having it you would not discuss the API because nobody respects TODOs. Did I miss something? In the past we have bundeled even stuff that has not been stable or in a mature state. Well, THAT is a nice argument. We've fucked it up in the past, let's do it again, huh? Phar is stable. All I said is that we won't do the same mistake again. PECL/json, PECL/zip and the others were/are stable too. That doesn't mean there are no bugs we don't know of. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. How speed of the tests would depend on speed of the loading phpunit runner? I don't believe reading a couple of files phpunit runner needs with PHP would do much difference compared to reading same files with C. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: I also just realized, these are also all tools where you probably do not want APC to store the bytecode in memory. Furthermore it is however still quite useful to have your unit test executing quickly. How speed of the tests would depend on speed of the loading phpunit runner? I don't believe reading a couple of files phpunit runner needs with PHP would do much difference compared to reading same files with C. Yes, of course if you are looking to run 1 hour worth of unit tests, the initial load up time is not relevant. But if you just want to quickly run the tests that you feel are most likely affected, the start up time is relevant. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/09/2007 02:00 AM, Marcus Boerger wrote: Hello Antony, it make it much harder as you would need to load PHP_Archive before you can do anything else with them. It would mean you cannot easily execute them unless they contain PHP_Archive themselves It's harder for those who create phars, but there is no difference for those who use phars. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Pierre, Tuesday, May 8, 2007, 10:59:08 PM, you wrote: On 5/8/07, Davey Shafik [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, not in other words. I said the words I said, because I meant those words. I'm talking about small *production* deployments. I don't see Why small deployment can't use PHP phar then? If they don't use bytecode cache parsing PHP on each request obviously isn't a problem for them. Because sometimes you like to not waste resources unnecessarily? Maybe because their host only allows default PHP config and doesn't provide PEAR or PECL? Given that either PHP_Archive or pecl/phar are not required to execute a phar, I really don't see the point here. There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to a situation where practically every phar would have to include the PHP_Archive.Which would be suboptimal. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: include to work on those. Making a hack in PHP to allow phar:// streams to work is a bad idea, a C-extension can easily work here. So from now on, every time we would want to user stream we'd have to do C extension and all user stream functionality in PHP is just useless? And all that for some weird reincarnation on safe mode again? I don't know how it sounds for you, but form be it sounds really broken way to do things - throwing perfectly good and working userspace streams because of pseudo-security configurations. Hi, I'd like to remind everyone that I brought up this issue when it was originally proposed to make userspace streams always remote and to disable allow_url_fopen/allow_url_include. This was in the days when Esser was still around, to put it in context. The only solution that would allow userspace streams to function *and* allow security would be to implement safe_mode 2.0: disable all remote access functions when inside a streams handler. The implementation is actually quite simple on the surface, but immensely complex in reality, as it would require combing through every internal PHP function or class that can possibly access the outside world, and disabling it. Otherwise users will be able to circumvent all_url_fopen by writing a simple stream wrapper that just downloads the crap and returns it as an $fp. However, could we take another look at the purpose of allow_url_include/fopen? Isn't it to prevent stupid users from shooting themselves in the foot with code like: ?php $a = fopen($_GET['dumbidea']); include $_GET['waystupididea']; ? allow_url_include/allow_url_fopen do not prevent users from downloading code and executing it intentionally, this is the job of a firewall. I know the idea of a taint mode was sort of discarded (I think it was, that was one lng thread), but realistically, this is probably the better way to a more secure fopen and include without a more difficult safe mode-esque solution. All security experts say security is a tradeoff between convenience and safety, and the convenience of userspace stream wrappers will simply disappear in the name of the safety of preventing remote code execution vulnerabilities. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to Yes, the whole whopping 20K of space uncompressed and with comments, so could be probably 10K or less without comments, whitespace and minimized for extraction. Serious waste of bandwidth worth discussing. a situation where practically every phar would have to include the PHP_Archive.Which would be suboptimal. That would be suboptimal if we suppose everybody uses phar archives. Since it is not the case and most apps would neither run in phars nor require to be run from phars without extraction, optimizing PHP for use in these use cases in not necessary. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
The only solution that would allow userspace streams to function *and* allow security would be to implement safe_mode 2.0: disable all remote No, that's not the only solution. Other solution would be stop trying to do what should be done on entirely other level and do it on the OS level, not try to make PHP what it is not - PHP is not built to securely limit the programmer and all attempts to do that eventually lead to the same problems safe_mode had. Or worse, if they break perfectly good code on the way. that can possibly access the outside world, and disabling it. Otherwise users will be able to circumvent all_url_fopen by writing a simple stream wrapper that just downloads the crap and returns it as an $fp. I say if you don't want your users to contact outside world, buy a firewall. allow_url_include was intended to serve very specific purpose, to plug hole created by often-written stupid code. It's not a comprehensive security solution and was not intended to restrict the programmer. I know the idea of a taint mode was sort of discarded (I think it was, Actually, AFAIK it wasn't :) disappear in the name of the safety of preventing remote code execution vulnerabilities. There would be no safety and no prevention, just plugging one way of thousands. IMHO it is pointless. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: There is no reason to have PHP_Archive in a phar. No need whatsoever... it would be a waste of space! Not having the extension would lead to Yes, the whole whopping 20K of space uncompressed and with comments, so could be probably 10K or less without comments, whitespace and minimized for extraction. Serious waste of bandwidth worth discussing. Yeah, I do not think that the size is really that big of an issue in this case. It would just be a code management inconvenience (having to update the same thing in all your applications, which requires downloading an new version of the application in its entirety etc.). @Greg: Do you have any benchmark result ready to compare the difference in start up cost? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Sunday, May 06, 2007 11:12 AM To: Marcus Boerger Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Starting 5.3 IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi, On 5/7/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: pear install phar - or - pecl install phar - done oh wait the point is that pecl install doesn't work or is in 99% no option And what is pear install? I don't have such command in my Windows by default. Neither I have it on my Linux. I would have to install PEAR for that, right? Even only to know what's inside. A little note about executing a phar file, no phar extension is required to execute a phar archive, neither to create it (see http://pear.php.net/package/PHP_Archive) . We distribute pear.phar since a couple of stable releases already. It is easier/faster to create it using pecl/phar. I'm sure there is a big difference (performence) when a phar is executed with or without pecl/phar, it is slow anyway. I see this extension as a packager tool only (where end users are packages user). NB: Recent changes in the extensions may be available only in the extension, I did not follow its recent developments. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
A little note about executing a phar file, no phar extension is required to execute a phar archive, neither to create it (see Right, but php and PEAR are required to read/create/inspect the archive. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi, On 5/7/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: A little note about executing a phar file, no phar extension is required to execute a phar archive, neither to create it (see Right, but php and PEAR are required to read/create/inspect the archive. Who has inspected pear.phar? Not a lot I think, but we all installed pear using at least once (without ext/phar). Not pear directly but PHP_Archive or the pecl/phar. However phar is good to test something in a non intrusive way (no file to install, you can do php foo.phar or run it in a webserver if you rename it to .php) or as a self contained installer. But I would not recommend to ever use a phar for other purposes like in a production environment. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
.php) or as a self contained installer. But I would not recommend to ever use a phar for other purposes like in a production environment. That's the question - if phar is not to be recommended in production as deployment format, it belongs to PECL. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 7:07:09 AM, you wrote: they most likely don't, it is designed for deployment and for running includes directly. What do you mean directly? Do you mean this is designed for running application only specifically crafted to run inside phar and would break some or most of the existing applications not designed specifically for it? Then even less reason to recommend it as a way to deploy real applications. It means you can run a phar file. How is that so hard to understand. See the docs: http://php.net/phar pear install phar - or - pecl install phar - done oh wait the point is that pecl install doesn't work or is in 99% no option And what is pear install? I don't have such command in my Windows by default. Neither I have it on my Linux. I would have to install PEAR for that, right? Even only to know what's inside. Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. slow? bigger? overhead? Meaning, of no practical use nobody would package their real-world apps this way. Then I guess it's not really an option? As said you can try stuff in a phar and then extract it. And lemme think, a war or jar or whatever crap doesn't make java faster either. But hey it would be a nice trick to turn PHP evenmore into Java so you should promote it. Interesting and not maintained for the most. Sometimes working on one or the other very specific php version only. And often even without documentation. This is as I see for very specific applications too, and the manual says there's no currently stable version of phar. Strange, pecl lists three stable versions since end of march: http://pecl.php.net/package/phar And phar has been stable since end of last year. We only decided to not mark it stable to be able to rename a few things. My opinion I see is that it is not right to recommend it as preferred way to deploy PHP applications. I know there are many people that it suits their needs - but those people as I understand have to keep in mind they work for phar anyway, so they might as well install one more extension. Once again, that is in most cases no option at all. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
It means you can run a phar file. How is that so hard to understand. It is not hard to understand. What seems to be hard to understand is that the scenario you describe is by no way the only scenario PHP files run in. Not all applications are single entry point and of those that are, not all applications are suitable to work in non-filesystem environment. Thus using phar in applications not specifically designed for it and in environments which presume files are in filesystem might prove harder than some think. a war or jar or whatever crap doesn't make java faster either. But hey it would be a nice trick to turn PHP evenmore into Java so you should promote it. If it was meant as some kind of a jab I'm afraid it was lost on me, I don't understand how it is relevant to anything, sorry. :) Strange, pecl lists three stable versions since end of march: http://pecl.php.net/package/phar I guess you should fix the manual then :) Once again, that is in most cases no option at all. How it's no option in most cases? And while we are at it, what is the most cases anyway? Is that most PHP deployments including millions of hosting clones all alike or most people supposed to use packaged applications (as opposed to writing own PHP scripts) or most people running complex production environments (as opposed to just playing with some private site) or most of what? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
phar is a good way of deploying PHP code, as PEAR proves. As a cautious developer however, I am reluctant to using optional features that might not be available on my client's installation. And for regular users of PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Andi Gutmans wrote: I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. It seems to me that there are even more people around with their own agendas today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for me, so my next step WOULD be PHP6. For those of us who have already 'dropped' register_globals and magic_quotes in our code, forcing people who have not yet had time to make the move seems a little heavy handed. PHP6 will need a major porting exercise, so keep it until then. As for phar? It sounds a little like PDO. No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Proper discussion and development of elements that are planned to become main stream would be nice, and not the apparently current method of 'I'm doing this in the next release because I want it!' Do we need phar? Is it fully operational on all platforms? How will the currently registered dependencies be addressed? IF it goes into the main distribution presumably the installers are going to be extended to support it's server requirements. Is that appropriate 'mid cycle'? It WOULD be nice to spend some time inside the PHP code base, but at present all spare time seems to be spent monitoring and testing all the changes to the releases and always playing catch up. PHP6 is the next release - PHP5 should now be tied down and put on the same basis as PHP4 before we end up with even more private initiatives creating even more mayhem :( If people want these changes why aren't they working to get PHP6 out? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Unless your clients immediately upgrade to php 5.3 this is the case anyway for some time (probably measured in years). Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. If it's the installer question you could do it in a number of other ways, but phar way is OK too. It would be one thing to use phar-like format as a packaging format used as base for installers (akin to .msi, .rpm, etc) - and as I understand, it is achievable even without having phar extension with the same success (performance is not really a thing for installer). However, running live app from inside phar is entirely different thing. IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. That's exactly what I am saying - that in my opinion such format is not the best thing PHP software developers could (or should) rely on in many scenarios. Putting something in PHP source is a form of endorsement, and I think it should be carefully considered if it's ready for all scenarios before we do that. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stefan Priebsch wrote: phar is a good way of deploying PHP code, as PEAR proves. As a cautious developer however, I am reluctant to using optional features that might not be available on my client's installation. And for regular users of PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. And given the problem getting hosts to ADD PECL extensions, you expect that they will allow a third party application to install things on their locked down machines. I think the first problem is how does it integrate with hosting environments and will those hosts allow it to run? IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 10:04:16 AM, you wrote: PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Unless your clients immediately upgrade to php 5.3 this is the case anyway for some time (probably measured in years). I guess we immediately stop unicode development then. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev schrieb: Unless your clients immediately upgrade to php 5.3 this is the case anyway for some time (probably measured in years). Sure. But since PHP4 support is discontinued by the end of this year, people will have to upgrade to 5.x (or 6) anyway. That would put phar support in the broad field maybe by mid-year 2008. for installer). However, running live app from inside phar is entirely different thing. I fully agree to that. I (currently) see phar as a means of deploying PHP code. But when people start running PHP apps from a phar, I am sure that soon some caching mechanism will appear that would just extract the files from the phar to the file system for quicker access - which again would make phar a great tool for deploying PHP code. And, if APC becomes more wide-spread in the future, I guess it does not really matter wether the code is read from filesystem of phar for the first time, since subsequently the pre-compiled code would be read from the cache anyway. Thus, I see no serious performance impact even if you run software from phar, at least when using a bytecode cache. That's exactly what I am saying - that in my opinion such format is not the best thing PHP software developers could (or should) rely on in many scenarios. Putting something in PHP source is a form of endorsement, and I think it should be carefully considered if it's ready for all scenarios before we do that. Then, for installation, what other format would you suggest? I think one advantage of phar is that it is backed by PEAR tools that one can expect every PHP developer to have on his system. It would be a good time now to provide some kind of de-facto-standard for deployment of PHP code, and phar is the best candidate I know for this. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine schrieb: And given the problem getting hosts to ADD PECL extensions, you expect that they will allow a third party application to install things on their locked down machines. I think the first problem is how does it integrate with hosting environments and will those hosts allow it to run? Hmmm ... isn't the essence of PHP webspace to be able to put PHP scripts/applications there to run them? phar could make the installation of PHP scripts and applications easier as compared to uploading an archive, unzipping it, possibly fixing access rights manually. Any yes, they will allow it to run because it's no different from allowing PHP scripts to run. As a matter of fact, .phar cannot do anything that .php cannot do, but it's just one file which makes it way easier to handler for end-users. Kind regards Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
I fully agree to that. I (currently) see phar as a means of deploying PHP code. But when people start running PHP apps from a phar, I am sure Then you don't need any extension - install should run without it quite well. And, if APC becomes more wide-spread in the future, I guess it does not really matter wether the code is read from filesystem of phar for the It does. For starters, if you put whole multi-megabyte app in one file, you'd have to either load them all and waste a lot of memory or make bytecode caches implement pseudo-filesystem layer on top of it to do it efficiently. And then there are applications that actually use paths and __FILE__ and whatnot. the cache anyway. Thus, I see no serious performance impact even if you run software from phar, at least when using a bytecode cache. Besides performance impact, there's manageability impact. Think of how easy is to work with compiled code as opposed to dynamic language code. Then, for installation, what other format would you suggest? For installation - format compatible with existing tools (as most of the vendors already do). For runtime - I don't think running PHP out of the single huge file is a very good idea whatever the format is. I think one advantage of phar is that it is backed by PEAR tools that I think it's a disadvantage. With all due respect to the PEAR team and the tools, nobody in the world but PEAR team knows what this format is, and there's tens of years of tools to work with other formats, supported by all OSes and languages in existence. I know it works well in all ten use cases that was considered, but once we recommend it to the wide world, there would be thousands of cases it doesn't work. Unix was built on the principle of interoperability, and inventing private formats not supported by anything violates this principle. one can expect every PHP developer to have on his system. It would be a good time now to provide some kind of de-facto-standard for deployment of PHP code, and phar is the best candidate I know for this. I'd say the only one - and I don't think making decision about standard from this position - we never though of anything better and it just grew as it is so we make it standard is a good approach. It works for the thing is was built for - distributing PEAR files - but when we talking about PHP-wide policy I don't think we should recommend people running their applications out of phar files. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Marcus Boerger wrote: Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Fri, 4 May 2007, Lukas Kahwe Smith wrote: Ilia Alshanetsky wrote: On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote: Yes, to me the question is only if we want to give the message that software producers should be able to expect phar to be there on 99% of the systems. Thats the only way that phar has a good chance of really taking off as a php code distribution approach. It sounds like the merits of having phar is would only be apparent after it is included in the core and everyone starts using it because of that. This won't happen simply because most software producers can't rely on extensions that are only available in version X. No, the point is that if we want to push something, we need to add it sooner rather than later, because there will be a delay anyways. Also simply by putting it into core, we make sure that phar gets into the long terms plans of users (which are then more likely to accept the transition pain, because they know its going to be around and maintained). Right, so the question is whether we want to push it or not. What would be good reasons for adding phar to the core? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: It means you can run a phar file. How is that so hard to understand. It is not hard to understand. What seems to be hard to understand is that the scenario you describe is by no way the only scenario PHP files run in. Not all applications are single entry point and of those that are, not all applications are suitable to work in non-filesystem environment. Thus using phar in applications not specifically designed for it and in environments which presume files are in filesystem might prove harder than some think. So if you are wondering about use cases, the PEAR installer is a good example. Generally I would say phar lends itself for self installing applications, but also for applications you run infrequently, that are not that performance critical (which does not mean you want them to run extra slow either) and where you want minimal fuss in keeping an uptodate version. I do not see phar's be used as the runtime after installation for most applications of course. But a sizeable number of them could be run this way. Also it is one of those cases of build it and they will come. So once we put this into core, people will take notice, tools will be developed, others will be adapted to become compatible etc. Maybe we should for a moment shift the discussion from if its useful (because several half way smart people have said it is), to is it technically sensibly implemented. Just give these guys the benefit of the doubt on the usefulness part and make sure its good on the implementation part. regards, Lukas regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
On Sun, 6 May 2007, Mike Robinson wrote: It could well be the last chance to get the mail() logger into 5.x as well, and IMHO a lot of people are waiting for this that can't/won't migrate to PHP6 quickly. There is no reason why that can't go into PHP 5.2.3. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote: Marcus Boerger wrote: Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. .. even though it does not require Phar extension at all. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Sun, 6 May 2007, Lukas Kahwe Smith wrote: Ilia Alshanetsky wrote: IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. What would be the goal of that? Making it less painful to migrate to PHP 6.x since they already face similar pain when staying in the active 5.x branch? Well, as you know some developers do not really care about PHP 6 and just leave it lying around without the proper merged from stuff that are put in PHP_5_2 at the moment. IMO this is just another attempt to stall PHP 6 developed (and adoption). I would be against merging those two things back to PHP_5_2. There is no compelling reason to do so. However, something that *is* a good reason is some lower level engine stuff that people will actually benefit from. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Lester Caine wrote: Andi Gutmans wrote: I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. It seems to me that there are even more people around with their own agendas today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for me, so my next step WOULD be PHP6. For those of us who have already 'dropped' register_globals and magic_quotes in our code, forcing people who have not yet had time to make the move seems a little heavy handed. PHP6 will need a major porting exercise, so keep it until then. As for phar? It sounds a little like PDO. No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Proper discussion and development of elements that are planned to become main stream would be nice, and not the apparently current method of 'I'm doing this in the next release because I want it!' Do we need phar? Is it fully operational on all platforms? How will the currently registered dependencies be addressed? IF it goes into the main distribution presumably the installers are going to be extended to support it's server requirements. Is that appropriate 'mid cycle'? It WOULD be nice to spend some time inside the PHP code base, but at present all spare time seems to be spent monitoring and testing all the changes to the releases and always playing catch up. PHP6 is the next release - PHP5 should now be tied down and put on the same basis as PHP4 before we end up with even more private initiatives creating even more mayhem :( If people want these changes why aren't they working to get PHP6 out? Amen, besides that you should use php 5.2 and not 5.1.6 ;-) regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Antony Dovgal wrote: On 05/06/2007 10:11 PM, Ilia Alshanetsky wrote: IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. That's exactly the reason I'm against creating 5_3 branch at this moment - I'm afraid that you (and everybody else) will start patching it and 5_2 will become 4_4 as it is now - security fixes only.. once in a month.. maybe.. or maybe not. You would be busy with 5_3, even though there is enough work in 5_2 branch. Yes, and development should not be done in a branch anyway, but in HEAD. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Derick Rethans wrote: PHP6 is the next release - PHP5 should now be tied down and put on the same basis as PHP4 before we end up with even more private initiatives creating even more mayhem :( If people want these changes why aren't they working to get PHP6 out? Amen, besides that you should use php 5.2 and not 5.1.6 ;-) Perhaps when I get some time to find out why the code will not run on 5.2 but is fine on 5.1.6 ;) But now need to set the test machine up with 5.2.2 and start testing again. If we knew that there were no problems installing an update life would be easier, but the time it takes to fully test all options every time simply BECAUSE we know things will need changing . -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
