Hi!
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.
https://wiki.php.net/rfc/pecl_http
[1] https://github.com/php/pecl-http-pecl_http/tree/phpng
[2] https://github.com/php/pecl-php-propro/tree/phpng
[3] https://github.com/php/pecl-php-raphf/tree/phpng
For a test run with master, clone into ext/ and configure --with-http --enable-propro --enable-raphf after buildconf.
Let me know if it doesn't work out of the box for you.
I'll have to update the corresponding links in the RFC to the phpng
branches and refresh the code coverage reports in the next few days.
Reminder!
Do not look at php.net/http; API docs are here:
http://devel-m6w6.rhcloud.com/mdref/http/
--
Regards,
Mike
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.
The RFC doesn't mention if you intend for it to be enabled by default
or just included with the php-src repository. I can reasonably see
this detail influencing the way someone would vote, so can you please
update the RFC accordingly?
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.The RFC doesn't mention if you intend for it to be enabled by default
or just included with the php-src repository. I can reasonably see
this detail influencing the way someone would vote, so can you please
update the RFC accordingly?
I’m not sure why that would directly influence a yay/nay but I guess we could either make a 3-way poll or a separate vote on enabling it by default?
Regards,
Mike
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.The RFC doesn't mention if you intend for it to be enabled by default
or just included with the php-src repository. I can reasonably see
this detail influencing the way someone would vote, so can you please
update the RFC accordingly?
I updated the RFC to mention a three-way vote:
- yes, enabled by default
- yes, disabled by default
- no
--
Regards,
Mike
Hi!
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.https://wiki.php.net/rfc/pecl_http
[1] https://github.com/php/pecl-http-pecl_http/tree/phpng
[2] https://github.com/php/pecl-php-propro/tree/phpng
[3] https://github.com/php/pecl-php-raphf/tree/phpngFor a test run with master, clone into ext/ and
configure --with-http --enable-propro --enable-raphfafter buildconf.Let me know if it doesn't work out of the box for you.
I'll have to update the corresponding links in the RFC to the phpng
branches and refresh the code coverage reports in the next few days.Reminder!
Do not look at php.net/http; API docs are here:
http://devel-m6w6.rhcloud.com/mdref/http/
I am still all for it :)
By the way, I did not yet look more deeply to raphf and propro but
that's something I like to discuss. If their feautures are useful for
other parts of the core, extensions, bundled or not, we should
consider moving them to the main APIs and not as two new independent
extensions.
--
Pierre
@pierrejoye | http://www.libgd.org
Hi!
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.https://wiki.php.net/rfc/pecl_http
[1] https://github.com/php/pecl-http-pecl_http/tree/phpng
[2] https://github.com/php/pecl-php-propro/tree/phpng
[3] https://github.com/php/pecl-php-raphf/tree/phpngFor a test run with master, clone into ext/ and
configure --with-http --enable-propro --enable-raphfafter buildconf.Let me know if it doesn't work out of the box for you.
I'll have to update the corresponding links in the RFC to the phpng
branches and refresh the code coverage reports in the next few days.Reminder!
Do not look at php.net/http; API docs are here:
http://devel-m6w6.rhcloud.com/mdref/http/I am still all for it :)
By the way, I did not yet look more deeply to raphf and propro but
that's something I like to discuss. If their feautures are useful for
other parts of the core, extensions, bundled or not, we should
consider moving them to the main APIs and not as two new independent
extensions.
Well, I’m not the one to tell you that :) If I didn’t find it useful, I wouldn’t have built it.
Don’t hesitate, if there are questions about what they conceptually are trying to accomplish.
I think a short discussion about where to put the dependant code and noting the outcome in the RFC could be the way to go. I guess just a few people who think that pecl_http is about to be included would suffice.
Best regards,
Mike
Well, I’m not the one to tell you that :) If I didn’t find it useful, I wouldn’t have built it.
Don’t hesitate, if there are questions about what they conceptually are trying to accomplish.I think a short discussion about where to put the dependant code and noting the outcome in the RFC could be the way to go. I guess just a few people who think that pecl_http is about to be included would suffice.
I started using PHP one windows, and so have always viewed it as a
smaller core and a series of modules. SUSE continues that model and I
see no reason to change now, so in my book it is the the current
bundling and enabling by default that has always been the wrong
approach. I simply enable the elements I need and leave out all the
other stuff which I don't. So the debate should be if other 'dependant
code' exists. A large section of the ini file relates to modules which
may well not be enabled so that gets deleted and moved to the relevant
sub.ini .
You are already talking about pushing php_interbase and other extensions
into pecl, so they can be ignored but we got agreement a long time ago
that no one database would be enabled by default, so all should be
easily available. I would probably add that for a long time now I think
most distributions have bundled mysql and mysqli in the one package, so
the idea of removing mysql may not be so easy to achieve.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Thu, Jan 22, 2015 at 5:32 PM, Michael Wallner mike@php.net
wrote:Hi!
Now, that I'm mostly done with porting pecl/http [1] and
dependencies (propro [2] and raphf [3]) to ZE3 I'd like to
restart discussion on the topic, whether it is feasible to add
pecl_http as a bundled extension to the core.
[...]
By the way, I did not yet look more deeply to raphf and propro but
that's something I like to discuss. If their feautures are useful
for other parts of the core, extensions, bundled or not, we should
consider moving them to the main APIs and not as two new
independent extensions.
[...]
I think a short discussion about where to put the dependant code and
noting the outcome in the RFC could be the way to go. I guess just a
few people who think that pecl_http is about to be included would
suffice.
I just pushed a tree with pecl/http merged to ext/http, pecl/propro
merged to ext/standard and pecl/raphf merged to main/.
https://github.com/m6w6/php-src/tree/merge-http
--
Regards,
Mike
On Thu, Jan 22, 2015 at 5:32 PM, Michael Wallner mike@php.net
wrote:Hi!
Now, that I'm mostly done with porting pecl/http [1] and
dependencies (propro [2] and raphf [3]) to ZE3 I'd like to
restart discussion on the topic, whether it is feasible to add
pecl_http as a bundled extension to the core.[...]
By the way, I did not yet look more deeply to raphf and propro but
that's something I like to discuss. If their feautures are useful
for other parts of the core, extensions, bundled or not, we should
consider moving them to the main APIs and not as two new
independent extensions.[...]
I think a short discussion about where to put the dependant code and
noting the outcome in the RFC could be the way to go. I guess just a
few people who think that pecl_http is about to be included would
suffice.I just pushed a tree with pecl/http merged to ext/http, pecl/propro
merged to ext/standard and pecl/raphf merged to main/.
Nice move!! Thanks :)
I am all for it :)
--
Regards,
Mike
Hi Mike,
Now, that I'm mostly done with porting pecl/http [1] and dependencies
(propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the
topic, whether it is feasible to add pecl_http as a bundled extension to
the core.
Could you include http_build_query() modification in the RFC?
http_build_query() escapes ' ' as '+' currently. It should be '%20'.
I was about to proposing this change, but it was http_* function and
the change does not break scripts.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Could you include
http_build_query()modification in the RFC?
http_build_query()escapes ' ' as '+' currently. It should be '%20'.
I was about to proposing this change, but it was http_* function and
the change does not break scripts.
I don’t think that belongs to this RFC, Yasuo.
But I’m +1 on your request, because it seems a no-brainer.
Cheers,
Mike
Could you include
http_build_query()modification in the RFC?
http_build_query()escapes ' ' as '+' currently. It should be '%20'.
I was about to proposing this change, but it was http_* function and
the change does not break scripts.I don’t think that belongs to this RFC, Yasuo.
But I’m +1 on your request, because it seems a no-brainer.
BTW, there already is PHP_QUERY_RFC3986.
Mike
Hi Mike,
Could you include
http_build_query()modification in the RFC?
http_build_query()escapes ' ' as '+' currently. It should be '%20'.
I was about to proposing this change, but it was http_* function and
the change does not break scripts.I don’t think that belongs to this RFC, Yasuo.
But I’m +1 on your request, because it seems a no-brainer.BTW, there already is PHP_QUERY_RFC3986.
Yes there is. I will propose changing the default.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net