On Fri, 10 Jun 2011 13:39:34 +0200, Johannes Schlüter
wrote:
On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote:
As far as I can see there are very few extension that are really needed
in
the core, the main problem comes from distributions changing the methods
that PECL works or the core wor
On Fri, Jun 10, 2011 at 12:50 PM, Lars Strojny wrote:
> Please change your tone.
+1!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote:
> As far as I can see there are very few extension that are really needed in
> the core, the main problem comes from distributions changing the methods
> that PECL works or the core works
>
> e.g.
> Ubuntu you need to install the -dev version in or
As far as I can see there are very few extension that are really needed in
the core, the main problem comes from distributions changing the methods
that PECL works or the core works
e.g.
Ubuntu you need to install the -dev version in order for extension to be
compiled/installed
Gentoo you need to
Am 10.06.11 11:20 schrieb "Reindl Harald" unter :
>let the api fuck in peace or you risk that the extension will not used
>in the future because you force all users to totally change their
>projects with
>the fear that 5 years later 3.0.0 breaks all baackward compatibility again
Please change you
On Fri, 10 Jun 2011 11:29:44 +0200, Pierre Joye wrote:
> On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner wrote:
>
>> I started the rewrite of the extension, because it had one really big
>> drawback, namely that message bodies where implemented as memory chunk
>> instead of streams. The next ma
On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner wrote:
> I started the rewrite of the extension, because it had one really big
> drawback, namely that message bodies where implemented as memory chunk
> instead of streams. The next major headache caused the confusion which
> the HttpResponse clas
On 9 Jun 2011 20:11, "Michael Wallner" wrote:
> I started the rewrite of the extension, because it had one really big
> drawback, namely that message bodies where implemented as memory chunk
> instead of streams. The next major headache caused the confusion which
> the HttpResponse class was resp
Am 09.06.2011 20:11, schrieb Michael Wallner:
> In the past many developers did not feel comfy enough with the pecl_http
> extension. It had been proposed for inclusion in the core distribution
> for a few times, but people always had doubts about the API etc.
i do not understand why
> Anothe
On Sun, 05 Jun 2011 13:37:36 +0200, Reindl Harald wrote:
> http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of
> 5.3 lifecycle a total incompatible reqrite is started and hopefully no
> one has projects relying on the pecl-extension
In the past many developers did not feel comfy
> Please don't forget that it's possible to host your database apart from your
> main code. Mongolab[1]
While this is technically true, and as much as I love MongoDb, for all
practical purposes this isn't really useful. The latency on these sorts of
connections is generally totally unacceptable
2011/6/7 Johannes Schlüter :
> That's why there are package
> managers or the windows Installer bundling some PECL stuff (or MSFT's
> Web Installer thingy)
The msft thingy as you call it does not support update and is a simple
wrapper around our own installer (which uses MSI).
We (php-win) woul
On 06/06/2011 10:56 AM, Johannes Schlüter wrote:
On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote:
The only way, currently, that projects can predict what a given host
will have installed is "bundled in core PHP". If it's in the core PHP
bundle, we can *usually* expect it to be there. I
> My reasoning is simple. The key for bundling extensions is to have
> them available for most hosting solutions. If a shared host provides
> support for mongodb, then he will most likely enable the mongodb
> extension in php, if he knows what he is doing. The same applies for
> all other non core
Am 07.06.2011 16:59, schrieb Martin Scotta:
> Most admins are not even aware of this, others really don't care -- how many
> host are up to date?
> So why relying on them?
2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011
httpd-2.2.19-2.fc14.rh.20110526.x86_64
apr-1.4.5-1.fc14.rh.2011
Martin Scotta
On Tue, Jun 7, 2011 at 6:32 AM, David Muir wrote:
> On 07/06/11 15:49, Reindl Harald wrote:
> >
> > Am 07.06.2011 04:42, schrieb Martin Scotta:
> >> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald >wrote:
> >>
> >>> Am 06.06.2011 23:40, schrieb Martin Scotta:
> >>>
> It'd be
On Tue, Jun 7, 2011 at 4:59 PM, Martin Scotta wrote:
>
>
> Martin Scotta
>
>
> On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs wrote:
>
>> On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald > >wrote:
>>
>> >
>> >
>> > Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
>> > > On Tue, Jun 7, 2011 at 3:04 PM, R
Martin Scotta
On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs wrote:
> On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald >wrote:
>
> >
> >
> > Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
> > > On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald > >wrote:
> > >
> > >>
> > >>
> > >> Am 07.06.2011 14:44,
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald wrote:
>
>
> Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
> > On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald >wrote:
> >
> >>
> >>
> >> Am 07.06.2011 14:44, schrieb David Muir:
> >>> On 07/06/11 18:40, Reindl Harald wrote:
> there is a reason for e
Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
> On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald wrote:
>
>>
>>
>> Am 07.06.2011 14:44, schrieb David Muir:
>>> On 07/06/11 18:40, Reindl Harald wrote:
there is a reason for example to disallow many functions
on a webserver - so every API has
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald wrote:
>
>
> Am 07.06.2011 14:44, schrieb David Muir:
> > On 07/06/11 18:40, Reindl Harald wrote:
> >> there is a reason for example to disallow many functions
> >> on a webserver - so every API has to make sure they
> >> can not be bypassed
> >>
> >>
Am 07.06.2011 14:44, schrieb David Muir:
> On 07/06/11 18:40, Reindl Harald wrote:
>> there is a reason for example to disallow many functions
>> on a webserver - so every API has to make sure they
>> can not be bypassed
>>
>> "because we can" is no valid reason for everything because
>> we can i
On 07/06/11 18:40, Reindl Harald wrote:
>
> Am 07.06.2011 11:32, schrieb David Muir:
>> On 07/06/11 15:49, Reindl Harald wrote:
>>> Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald
wrote:
> Am 06.06.2011 23:40, schrieb Martin Scotta:
Am 07.06.2011 11:32, schrieb David Muir:
> On 07/06/11 15:49, Reindl Harald wrote:
>>
>> Am 07.06.2011 04:42, schrieb Martin Scotta:
>>> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote:
>>>
Am 06.06.2011 23:40, schrieb Martin Scotta:
> It'd be very nice if some extension could b
On 07/06/11 15:49, Reindl Harald wrote:
>
> Am 07.06.2011 04:42, schrieb Martin Scotta:
>> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote:
>>
>>> Am 06.06.2011 23:40, schrieb Martin Scotta:
>>>
It'd be very nice if some extension could be enabled just by dropping the
"extension file"
Am 07.06.2011 04:42, schrieb Martin Scotta:
> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote:
>
>>
>> Am 06.06.2011 23:40, schrieb Martin Scotta:
>>
>>> It'd be very nice if some extension could be enabled just by dropping the
>>> "extension file" on the path.
>>> So developers can check wh
Martin Scotta wrote:
It'd be very nice if some extension could be enabled just by dropping the
"extension file" on the path.
So developers can check what they have using phpinfo, and then upload the
needed extension using ftp. Is it possible?
if a "developer" only would try such idiotic action
Martin Scotta
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote:
>
> Am 06.06.2011 23:40, schrieb Martin Scotta:
>
> > It'd be very nice if some extension could be enabled just by dropping the
> > "extension file" on the path.
> > So developers can check what they have using phpinfo, and then
Am 06.06.2011 23:40, schrieb Martin Scotta:
> It'd be very nice if some extension could be enabled just by dropping the
> "extension file" on the path.
> So developers can check what they have using phpinfo, and then upload the
> needed extension using ftp. Is it possible?
if a "developer" only
Martin Scotta wrote:
It'd be very nice if some extension could be enabled just by dropping the
"extension file" on the path.
So developers can check what they have using phpinfo, and then upload the
needed extension using ftp. Is it possible?
This depends on what distribution you are using in L
On Mon, 2011-06-06 at 18:40 -0300, Martin Scotta wrote:
> It'd be very nice if some extension could be enabled just by dropping the
> "extension file" on the path.
> So developers can check what they have using phpinfo, and then upload the
> needed extension using ftp. Is it possible?
No sane sysa
On Mon, 2011-06-06 at 12:53 -0400, Matthew Weier O'Phinney wrote:
> > But one thing is sure, all distributions do include mongodb,
> > memcache(d), couchdb, etc. If you can't run an apt-get install
> > memcached (non core), just like you run apt-get install pdo_mysql
> > (core), then there is somet
On Mon, Jun 6, 2011 at 11:40 PM, Martin Scotta wrote:
> Martin Scotta
>
>
> On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye wrote:
>
> > On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
> > wrote:
> >
> > > My point is that perhaps PHP has missed the boat a bit by moving
> > > everything int
Martin Scotta
On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye wrote:
> On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
> wrote:
>
> > My point is that perhaps PHP has missed the boat a bit by moving
> > everything into extensions. Perhaps if an extension is particularly
> > popular, it sh
On Sat, 4 Jun 2011, Andi Gutmans wrote:
> For starters I would bundle ext/mongo which is very well maintained;
> see if we can get "thrift_protocol" contributed to PECL and included
> (support HBase and Cassdandra and used by a few PHP SDKs integrating
> with these data stores).
I generally ag
On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
wrote:
> My point is that perhaps PHP has missed the boat a bit by moving
> everything into extensions. Perhaps if an extension is particularly
> popular, it should be incorporated into core. But let USAGE drive that,
> not the opinions of i
On 2011-06-05, Pierre Joye wrote:
> It sounds like persons doing these inquiries do not know PHP, its
> environment and how it works, neither they know that 99% of the linux
> distribution (and in some extend on windows too) provide most of the
> modern extensions with their standard distribution
On 2011-06-05, Pierre Joye wrote:
> On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson
> wrote:
>
> > I can't think of a statement I would disagree more with. These are
> > exactly the ones we should be bundling.
>
> > > My reasoning is simple. The key for bundling extensions is to have
> > > them
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield wrote:
> For me the question isn't "should we bundle memcached in PHP core", it's
> "how do we establish an expected baseline of PHP components that developers
> can reasonably expect will be available, and what should be in that?" Right
> now, that
On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote:
> The only way, currently, that projects can predict what a given host
> will have installed is "bundled in core PHP". If it's in the core PHP
> bundle, we can *usually* expect it to be there. If not, we can
> *usually* presume it won't
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield wrote:
> On 6/5/11 7:54 AM, Ferenc Kovacs wrote:
>
> just for the record, I agree with Pierre on this one.
>> our userbase has two distinct group: those who are using shared hosting
>> and
>> usually use some third party cms or write their own crappy
On 6/5/11 7:54 AM, Ferenc Kovacs wrote:
just for the record, I agree with Pierre on this one.
our userbase has two distinct group: those who are using shared hosting and
usually use some third party cms or write their own crappy suboptimal code,
and those who use php to build bleeding edge custo
there is no need to bundle GeoIP or the databae
GeoIP is part of the os-deployment and the database have
to be updated every month with a script, the problem here
was only that nobody cared about the extension over years
Am 06.06.2011 00:21, schrieb Scott MacVicar:
> Can't bundle geoip with the d
Can't bundle geoip with the database due to the license on it. Would make it a
pretty useless extension to have in that case.
S
On 5 Jun 2011, at 11:39, Olivier Hill wrote:
> Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
> around.
>
> Thanks
>
> Olivier (iPho
Hello everyone,
The following categorizes bundled/enabled/core, and lists extensions as they
stand today (compiled via snaps). I don't exactly know what this means, but
writing this feels appropriate:
- Bundled : An extension that is bundled
* ./configure --enable-ext (or --with-ext) is a
done
http://pecl.php.net/bugs/bug.php?id=2274
BTW:
that PHP 5.3.5 is the highest version in the dropdown for bugreports
does not provide the feeling of maintaining
Am 05.06.2011 20:39, schrieb Olivier Hill:
> Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
> around.
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
around.
Thanks
Olivier (iPhone)
Le 2011-06-05 à 04:37, Reindl Harald a écrit :
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the
(Andi - I sent this before going out this morning - but I can't see it on the
list this evening ... )
Andi Gutmans wrote:
I think one of the problems is that in the past we always ensured that the
extensions for key current technologies were bundled with PHP i.e. mysql, json&
soap/xml. This
On 06/05/2011 09:06 AM, Reindl Harald wrote:
> Am 05.06.2011 13:58, schrieb Rasmus:
>> On 06/05/2011 08:50 AM, Reindl Harald wrote:
Also some exts are simply not used anymore or do not have active
developers
>>>
>>> but they compile with recent 3versions and if not
>>> the build will sto
On Sat, 2011-06-04 at 23:00 +, Andi Gutmans wrote:
> Hi,
>
> I've been getting quite a few inquiries re: PHP's "lack" of support
> for modern technologies such as NoSQL databases (for lack of better
> term). There is some (mistaken) perception that PHP is behind on this
> front.
I'm in the b
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald wrote:
>
>
> Am 05.06.2011 13:40, schrieb Pierre Joye:
> > hi,
> >
> > On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald
> wrote:
> >> Am 05.06.2011 12:57, schrieb Pierre Joye:
> >>
> >>> The last point is that pecl allows a much more flexible release
> >
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson wrote:
> On Sun, Jun 5, 2011 at 12:57, Pierre Joye wrote:
> > However, for technologies specific extension, be hyped or not, I see
> > no reason to bundle them. It makes no sense to bundle mongodb,
> > memcached clients or whatever other specific
Am 05.06.2011 13:58, schrieb Rasmus:
> On 06/05/2011 08:50 AM, Reindl Harald wrote:
>>> Also some exts are simply not used anymore or do not have active
>>> developers
>>
>> but they compile with recent 3versions and if not
>> the build will stop and someone fix it
>
> Sorry, but that doesn't a
hi,
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald wrote:
>> Being in core is not a sign of good maintenance. There are so many
>> poorly maintained part in core as well.
>
> but they are running through some autotests
> a fucking PECL extension which is not updated
> for years and where bugrepor
On 06/05/2011 08:50 AM, Reindl Harald wrote:
>> Also some exts are simply not used anymore or do not have active
>> developers
>
> but they compile with recent versions and if not
> the build will stop and someone fix it
Sorry, but that doesn't actually happen. Only commonly used core things
are
On Sun, Jun 5, 2011 at 1:00 AM, Andi Gutmans wrote:
> For starters I would bundle ext/mongo which is very well maintained; see if
> we can get "thrift_protocol" contributed to PECL and included (support HBase
> and Cassdandra and used by a few PHP SDKs integrating with these data stores).
I se
Am 05.06.2011 13:40, schrieb Pierre Joye:
> hi,
>
> On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
>> Am 05.06.2011 12:57, schrieb Pierre Joye:
>>
>>> The last point is that pecl allows a much more flexible release
>>> management than the core will even do.
>>
>> in theory
>>
>>> So inste
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the core will even do.
>
> in theory
No, that's a fact. You can do releases whenever you want, at your own
wish.
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the core will even do.
>
> in theory
>
>> So instead of doing some marketing/communication actions by bundli
Am 05.06.2011 12:57, schrieb Pierre Joye:
> The last point is that pecl allows a much more flexible release
> management than the core will even do.
in theory
> So instead of doing some marketing/communication actions by bundling some
> known extensions, we should better promote pecl better.
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson
wrote:
> I can't think of a statement I would disagree more with. These are
> exactly the ones we should be bundling.
>> My reasoning is simple. The key for bundling extensions is to have
>> them available for most hosting solutions. If a shared h
On Sun, Jun 5, 2011 at 12:57, Pierre Joye wrote:
> However, for technologies specific extension, be hyped or not, I see
> no reason to bundle them. It makes no sense to bundle mongodb,
> memcached clients or whatever other specific features.
I can't think of a statement I would disagree more with
hi,
It sounds like persons doing these inquiries do not know PHP, its
environment and how it works, neither they know that 99% of the linux
distribution (and in some extend on windows too) provide most of the
modern extensions with their standard distribution.
For general purposes extensions or
How about the Yaml extension?, it looks well maintained enough:
http://pecl.php.net/package/yaml
Regards,
David
On Sun, Jun 5, 2011 at 2:33 AM, Hannes Magnusson wrote:
> On Sun, Jun 5, 2011 at 01:00, Andi Gutmans wrote:
> >
> > In parallel I'd also see if there are any key extensions which we
On Sun, Jun 5, 2011 at 01:00, Andi Gutmans wrote:
>
> In parallel I'd also see if there are any key extensions which we think are
> mainstream, stable and well maintained enough to be included. For example,
> http comes to mind.
>
People have been "afraid" of suggesting new exts to core due to
Hi All,
> In parallel I'd also see if there are any key extensions which we think are
> mainstream, stable and well maintained enough to be included. For example,
> http comes to mind.
With regards to the http extension, I've been using it in production
for a while, but ran into an issue where
Hi,
APC +1
I don't think it should have OAuth2 bundled (and I don't consider OAuth v1 too).
Related to thrift, I'm more in favor of having a native Cassandra
implementation than bundling thrift on PHP.
Thrift's implementation is not good (sorry Scott) and the overhead of
bootstrapping, connectin
On Jun 4, 2011, at 6:00 PM, Rasmus wrote:
> On 06/04/2011 09:03 PM, Scott MacVicar wrote:
>> On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote:
>>
>>> Hi!
>>>
In parallel I'd also see if there are any key extensions which we
think are mainstream, stable and well maintained enough to be
On 06/04/2011 09:03 PM, Scott MacVicar wrote:
> On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote:
>
>> Hi!
>>
>>> In parallel I'd also see if there are any key extensions which we
>>> think are mainstream, stable and well maintained enough to be
>>> included. For example, http comes to mind.
>>
>>
On 6/4/2011 8:55 PM, Philip Olson wrote:
In parallel I'd also see if there are any key extensions which we think are
mainstream, stable and well maintained enough to be included. For example, http
comes to mind.
Enable pecl_http by default (or, always), and bundle APC.
Regards,
Philip
APC, +
> In parallel I'd also see if there are any key extensions which we think are
> mainstream, stable and well maintained enough to be included. For example,
> http comes to mind.
Enable pecl_http by default (or, always), and bundle APC.
Regards,
Philip
--
PHP Internals - PHP Runtime Development
On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote:
> Hi!
>
>> In parallel I'd also see if there are any key extensions which we
>> think are mainstream, stable and well maintained enough to be
>> included. For example, http comes to mind.
>
> Maybe also oauth? It's getting popular and widely used.
Hi!
In parallel I'd also see if there are any key extensions which we
think are mainstream, stable and well maintained enough to be
included. For example, http comes to mind.
Maybe also oauth? It's getting popular and widely used.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.
73 matches
Mail list logo
