Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-13 Thread Christopher Jones
Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-13 Thread Gregory Beaver
Christopher Jones wrote: Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-13 Thread Steph Fox
Hi Chris, In interests of clarity for all, can you explain what you anticipate will change for PECL with Phar/Pyrus for Windows and non-Windows? From my PoV as a Windows user, the primary case for optimisim is based on the fact that local PEAR installs recently started working properly on

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Marco
You forget that for most shared hosters they just install PHP so that they can say they support it, but actually don't give a ratsass about what is actually supported. I totally agree, most hosts just install what comes as default with a distribution, they don't care or even bother with PECL

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Steph Fox
Hi both, I totally agree, most hosts just install what comes as default with a distribution, they don't care or even bother with PECL in 99% of cases in my experience. Well - that can't be entirely true or there'd be next to no MySQL support out there! I just think we make it needlessly

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Marco
Well - that can't be entirely true or there'd be next to no MySQL support out there! I knew that would come back and bite me on the ass as soon as I posted! :-) MySQL support is one of the noteable exceptions as its considered core to web-hosts (In their eyes PHP and MySQL are one) other

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Pierre Joye
On Feb 6, 2008 11:12 AM, Marco [EMAIL PROTECTED] wrote: Well - that can't be entirely true or there'd be next to no MySQL support out there! I knew that would come back and bite me on the ass as soon as I posted! :-) MySQL support is one of the noteable exceptions as its considered core

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Steph Fox
Hi Pierre, The main reason (from my experiences) for the ISP is lazynes. They don't care about what the users may need or not but simply run configure, make make install, or use the xyz distribtutions default package to run common applications like phpmyadmin or wordpress. That's a heck of an

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Steph Fox
Hi Marco, I think one of the reasons hosts don't like / use PECL is trust, they trust what comes with the PHP core packages and consider anything else a security risk. Maybe a combination of better distribution, package details, stability (beta / alpha) etc and maybe something that deals

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Pierre Joye
On Feb 6, 2008 11:32 AM, Steph Fox [EMAIL PROTECTED] wrote: Hi Pierre, The main reason (from my experiences) for the ISP is lazynes. They don't care about what the users may need or not but simply run configure, make make install, or use the xyz distribtutions default package to run

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Richard Quadling
On 06/02/2008, Steph Fox [EMAIL PROTECTED] wrote: By the way: http://www.nexen.net/articles/dossier/18038-base_configuration_for_php_5.2.5.php Thanks for that, Pierre. But I think those stats add to the argument for making PECL easier to deal with, rather than diminishing it. - Steph

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-06 Thread Steph Fox
By the way: http://www.nexen.net/articles/dossier/18038-base_configuration_for_php_5.2.5.php Thanks for that, Pierre. But I think those stats add to the argument for making PECL easier to deal with, rather than diminishing it. - Steph -- Pierre http://blog.thepimp.net |

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-05 Thread Richard Lynch
On Sat, February 2, 2008 2:14 pm, Steph Fox wrote: 2) Maintenance status needs to be part of the equation. 3) Stability needs to be part of the equation. 4) Appropriateness to a given PHP branch needs to be part of the equation. 5) CS and documentation need to be part of the equation.

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-05 Thread Richard Lynch
On Mon, February 4, 2008 3:42 am, Ben Trafford wrote: Just poking up my head to concur with Derick. What one person thinks of as 'fashionistas', another person will think of as absolutely core and necessary +1 I don't think this list will ever reach concensus on what should be in

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Derick Rethans
On Sat, 2 Feb 2008, Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Derick Rethans
On Sun, 3 Feb 2008, Steph Fox wrote: Everything else - the fashionistas (JSON, xmlreader/writer) and the downright useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky stuff (pretty much anything Sara came up with) - should be in PECL. I see another issue after

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Jani Taskinen
I'd like everything in PECL. Even the core. And yes, it is quite doable. --Jani On Sun, 2008-02-03 at 00:21 +0100, Marcus Boerger wrote: Hello Steph, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Jani Taskinen
On Sun, 2008-02-03 at 10:56 +0100, Lukas Kahwe Smith wrote: I am also not sure if including mysqlnd in PHP core is the way to go. However I would not be generally opposed to including it in the PHP distribution. There's a technical reason for that: It needs to be statically buildin to work

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Ben Trafford
At 04:33 AM 2/4/2008, Derick Rethans wrote: On Sun, 3 Feb 2008, Steph Fox wrote: Everything else - the fashionistas (JSON, xmlreader/writer) and the downright useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky stuff (pretty much anything Sara came up with) -

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Lukas Kahwe Smith
On 04.02.2008, at 11:38, Marcus Boerger wrote: Hello Ben, None of this is necessary though. What I proposed was moving extension development from php-src to PECL an dthen bundle what we see fit into the distribution just as we do now, whith the RM having the last say what goes in and

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Marcus Boerger
Hello Ben, None of this is necessary though. What I proposed was moving extension development from php-src to PECL an dthen bundle what we see fit into the distribution just as we do now, whith the RM having the last say what goes in and what not. In my proposal we would only put stuff into

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Steph Fox
Hi Derick, I see another issue after reading this, and that is that it makes it much harder for users to depend on specific extensions just being always available by default. It's important for application distributers to have this core set of extensions to rely on. It's annoying enough that

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-04 Thread Gregory Beaver
Steph Fox wrote: Hi Derick, I see another issue after reading this, and that is that it makes it much harder for users to depend on specific extensions just being always available by default. It's important for application distributers to have this core set of extensions to rely on. It's

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Lester Caine
Steph Fox wrote: Hi Marcus, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. What _I_ want is a PHP core that is really core. By that I mean things like: date,

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Lukas Kahwe Smith
On 03.02.2008, at 10:16, Lester Caine wrote: Steph Fox wrote: Hi Marcus, what I want is php-src as minimum you can depend on. And php- default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. What _I_ want is a PHP core that is

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Marcus Boerger
Hello Lukas, Sunday, February 3, 2008, 10:56:08 AM, you wrote: On 03.02.2008, at 10:16, Lester Caine wrote: Steph Fox wrote: Hi Marcus, what I want is php-src as minimum you can depend on. And php- default as release managers playground. The RM can then say what he thinks is mature

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Johannes Schlüter
Hi, On Sun, 2008-02-03 at 12:24 +0100, Marcus Boerger wrote: MySQLND was the last extension started in php-src and I don't even remember when this was discussed (though in the current structure I like it there pretty much). Actually it was developed internally to MySQL and offered for

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Hi Marcus, Anyway my idea is to start everything in PECL and to to move everything out that can be moved out. And that includes all MySQL extensions as well as SQLite. Only this way people will use the PELC infrastructure. Otherwise we would just reduce functionality of PHP. And btw nearly

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Hi Lukas, Correct me if I am wrong or if I am missing something, but currently things work more or less like this. I think its important that we get an understanding of how things are right now and what the issues are, before we go off and solve them (maybe with the above mentioned

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Lukas Kahwe Smith
On 03.02.2008, at 18:24, Steph Fox wrote: Hi Marcus, Anyway my idea is to start everything in PECL and to to move everything out that can be moved out. And that includes all MySQL extensions as well as SQLite. Only this way people will use the PELC infrastructure. Otherwise we would just

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Hi Lukas, I am not sure if I misunderstood some other persons proposal, but at least my proposal was that the final thing we ship as version xyz of PHP would include a set of PECL extensions along with core that we deem as necessary for the bulk of our users solving the web problem.

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Hi Marcus, The rest of the discussion is once again how easy it is to get more than the default distribution onto hosters machines. But a) I couldn't care less, That's... a bit remiss of you :) b) it is absolutely a discussion on its own and can addressed somewhere and somewhen else. No,

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Marcus Boerger
Hello Lukas, same here. I proposed php-src with absolute minimum. And php-default as the release state. Where the RM has the last say in what goes in and what not. The rest of the discussion is once again how easy it is to get more than the default distribution onto hosters machines. But a) I

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
With the risk to repeat myself (and some other having said the same), the biggest advantage PHP has so far is that you get everything you may need with the default install. This hasn't been true of the Windows distribution for the last few years. I think it should be - I think the default

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Pierre Joye
On Feb 3, 2008 10:21 PM, Steph Fox [EMAIL PROTECTED] wrote: With the risk to repeat myself (and some other having said the same), the biggest advantage PHP has so far is that you get everything you may need with the default install. This hasn't been true of the Windows distribution for the

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Good point but I admit that I never understood why our windows releases have been so different from the source releases, from a configuration point of view. Many default extensions are (were) not enabled. But that's not a big problem and can be easily fixed no? :) It's not a big problem so long

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Pierre Joye
On Feb 3, 2008 10:27 PM, Steph Fox [EMAIL PROTECTED] wrote: Good point but I admit that I never understood why our windows releases have been so different from the source releases, from a configuration point of view. Many default extensions are (were) not enabled. But that's not a big

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-03 Thread Steph Fox
Assuming the aim is to have everything _not_ enabled by default move to PECL, that's quite a big deal. That's another topic and I tend to disagree (more later on that). I'll wait... but I suspect all the arguments against that are based on PECL as it currently is, with all its distribution

[PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-02 Thread Steph Fox
Hi all, Just so's Marcus and I don't have to keep cross-posting here... The problems of PECL vs core extensions are many, and exist with or without the PDO/CLA debate. Marcus (among others) says he wants to get as many extensions as possible out of the core and into PECL. I agree fully with

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-02 Thread Pierre Joye
On Feb 2, 2008 9:14 PM, Steph Fox [EMAIL PROTECTED] wrote: Thoughts? It is also possible to have both. It is even a good thing for what linux distributions told me about zip. About moving all extensions to PECL, we already discussed this problem and the conclusion was to continue like now.

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-02 Thread Marcus Boerger
Hello Steph, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. marcus Saturday, February 2, 2008, 9:14:12 PM, you wrote: Hi all, Just so's Marcus and I don't

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-02 Thread Marcus Boerger
Hello Pierre, basically you are saying that zip would not have been used by anybody if you hadn't forced us by mail bombardment to include it. So now I am wondering why you care so much what goes in and what goes out? After all it is the RMs decision. And we might get asked or not. marcus

Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship

2008-02-02 Thread Steph Fox
Hi Marcus, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. What _I_ want is a PHP core that is really core. By that I mean things like: date, spl, pcre, zlib,