Personally, I don't like httpd being a hostage of apr. If 2.4.x
is such that using apr 2.x is precluded, so what? If apr 2.x
becomes such a great thing, we create httpd 2.6.x.
On 07/07/2011 08:44 PM, Nick Kew wrote:
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2])
(binding both apr and mod_ldap to ldap libs)
-1. OK for a hack, but not for a 2.4 release. Eat our own dogfood.
On 13 Jul 2011, at 16:54, Ruediger Pluem wrote:
On 07/07/2011 08:44 PM, Nick Kew wrote:
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2])
(binding both apr and mod_ldap to ldap libs)
-1. OK for a
On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction that isn't
needed in httpd is a valid technical
On Jul 12, 2011, at 8:20 AM, Joe Orton wrote:
On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction
On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wr...@rowe-clan.net wrote:
...
Which should be the combined revert of
http://svn.apache.org/viewvc?view=revisionrevision=1143225
http://svn.apache.org/viewvc?view=revisionrevision=1143222
On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction that isn't
needed in httpd is a valid technical reason to veto it
On 7/12/2011 2:12 PM, Greg Stein wrote:
On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wr...@rowe-clan.net
wrote:
...
Which should be the combined revert of
http://svn.apache.org/viewvc?view=revisionrevision=1143225
http://svn.apache.org/viewvc?view=revisionrevision=1143222
On Monday 11 July 2011, William A. Rowe Jr. wrote:
On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of
a new API to our product is a technical change that can be
vetoed. Likewise, the API being an incomplete abstraction that
isn't
On 12.07.2011 00:35, Stefan Fritsch wrote:
On Monday 11 July 2011, William A. Rowe Jr. wrote:
On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
Especially r1142938 needs checking, I think I may have accidentally
reverted some bits from that when resolving some conflicts.
I can check and reapply
On 7/11/2011 5:35 PM, Stefan Fritsch wrote:
On Monday 11 July 2011, William A. Rowe Jr. wrote:
On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of
a new API to our product is a technical change that can be
vetoed. Likewise, the API
Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction that isn't
needed in httpd is a valid technical reason to veto it even if
it had once been in apr-util.
Other than
On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction that isn't
needed in httpd is a valid technical reason to veto it
On 07.07.2011 18:55, William A. Rowe Jr. wrote:
Only presently available options are available as choices to end this
now unproductive discussion [any heretofore unseen complete abstration
of ldap cannot be considered with no patches offered]. This vote is
limited to the scope of the httpd
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk
(binding mod_ldap to ldap libs)
+1
(-0 at best on any of the others)
On 07 Jul 2011, at 6:55 PM, William A. Rowe Jr. wrote:
Only presently available options are available as choices to end this
now unproductive discussion [any heretofore unseen complete abstration
of ldap cannot be considered with no patches offered]. This vote is
limited to the scope of the
Only presently available options are available as choices to end this
now unproductive discussion [any heretofore unseen complete abstration
of ldap cannot be considered with no patches offered]. This vote is
limited to the scope of the httpd project and expresses a preference,
there is no
On Thu, Jul 7, 2011 at 12:55 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
Only presently available options are available as choices to end this
now unproductive discussion [any heretofore unseen complete abstration
of ldap cannot be considered with no patches offered]. This vote is
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk
(binding mod_ldap to ldap libs)
+1. But get it right: not a botch job just because there's
pressure to release. Should really have been alpha rather
On Jul 7, 2011, at 2:44 PM, Nick Kew wrote:
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk
(binding mod_ldap to ldap libs)
+1. But get it right: not a botch job just because there's
pressure to
On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote:
On Jul 7, 2011, at 2:44 PM, Nick Kew wrote:
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in
trunk
(binding mod_ldap to ldap libs)
+1. But get it right: not a
On 7/7/2011 5:16 PM, Graham Leggett wrote:
On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote:
On Jul 7, 2011, at 2:44 PM, Nick Kew wrote:
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote:
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk
(binding mod_ldap to ldap
22 matches
Mail list logo
