You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/04/11 16:41:22 UTC
Rolling APR[-util] 1.3.0
I'd like to proceed with this at the end of the weekend, unless
there is significant objection that we can't resolve.
The one side effect; it's not possible to "FIX" any API until
we release 2.0.0 - please take some time to look at the new API's
and think through if they solve our challenges, or if they need
to be more flexible.
Re: Rolling APR[-util] 1.3.0
Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2008-04-11 at 16:41 +0200, William A. Rowe, Jr. wrote:
> I'd like to proceed with this at the end of the weekend, unless
> there is significant objection that we can't resolve.
+1 and thanks!
--
Bojan
Re: Rolling APR[-util] 1.3.0
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
>>> Likewise for EVP interfaces,
>>> http://marc.info/?l=apr-dev&m=119574545706381&w=2 and
>>> http://marc.info/?l=apr-dev&m=119574538906243&w=2
>>>
>>> at least some of these problems will at require API changes to fix, so it
>>> seems dumb to ship as-is.
>> You posed these original two questions, but then didn't contribute further
>> to the discussions that followed.
>
> Your responses to the major issues were "This is a wider problem with
> the SSL code".
>
> What do you want to discuss, exactly?
Do these responses not address your concerns?
Regards,
Graham
--
Re: Rolling APR[-util] 1.3.0
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2008 at 12:59:22PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>
>> Likewise for EVP interfaces,
>> http://marc.info/?l=apr-dev&m=119574545706381&w=2 and
>> http://marc.info/?l=apr-dev&m=119574538906243&w=2
>>
>> at least some of these problems will at require API changes to fix, so it
>> seems dumb to ship as-is.
>
> You posed these original two questions, but then didn't contribute further
> to the discussions that followed.
Your responses to the major issues were "This is a wider problem with
the SSL code".
What do you want to discuss, exactly?
joe
Re: Rolling APR[-util] 1.3.0
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
> Likewise for EVP interfaces,
> http://marc.info/?l=apr-dev&m=119574545706381&w=2 and
> http://marc.info/?l=apr-dev&m=119574538906243&w=2
>
> at least some of these problems will at require API changes to fix, so
> it seems dumb to ship as-is.
You posed these original two questions, but then didn't contribute
further to the discussions that followed.
Regards,
Graham
--
Re: Rolling APR[-util] 1.3.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> at least some of these problems will at require API changes to fix, so
> it seems dumb to ship as-is.
so -- you are suggesting deferring these into 1.4.0?
> I would (again) suggest moving this stuff out onto a branch so those
> interested in making it work can do so without getting in the way of
> releases.
i've made it so; branches/1.3.x now exist for each of apr and apr-util.
Re: Rolling APR[-util] 1.3.0
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Apr 11, 2008 at 04:41:22PM +0200, William Rowe wrote:
> The one side effect; it's not possible to "FIX" any API until
> we release 2.0.0 - please take some time to look at the new API's
> and think through if they solve our challenges, or if they need
> to be more flexible.
I think APR looks good.
APR-util less so. Many of the problems with the SSL code have not been
resolved, http://marc.info/?l=apr-dev&m=117508244300387&w=2
Likewise for EVP interfaces,
http://marc.info/?l=apr-dev&m=119574545706381&w=2 and
http://marc.info/?l=apr-dev&m=119574538906243&w=2
at least some of these problems will at require API changes to fix, so
it seems dumb to ship as-is.
I would (again) suggest moving this stuff out onto a branch so those
interested in making it work can do so without getting in the way of
releases.
joe
Re: Rolling APR[-util] 1.3.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
> > I'd like to proceed with this at the end of the weekend, unless
> > there is significant objection that we can't resolve.
> >
> > The one side effect; it's not possible to "FIX" any API until
> > we release 2.0.0 - please take some time to look at the new API's
> > and think through if they solve our challenges, or if they need
> > to be more flexible.
> >
>
> IIUC 1.3 allows new functions added, correct?
Yes; not 1.3.1 though, so the API's should be complete from the start,
lest we land at 1.4.0 right away.
> If that's the case I have something to add by tomorrow.
> It's a new apr_pool API allowing to create 'detached'
> or 'standalone' pools. Those pools don't have parent
> and must be explicitly destroyed.
> This is particullary useful for embedding apr in systems
> with their own memory management (like Java).
> We are doing some really weird tricks in
> Tomcat and Mina just to deal with premature and zombie
> memory access.
Sounds cool - looking forward to the patch!
Re: Rolling APR[-util] 1.3.0
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> I'd like to proceed with this at the end of the weekend, unless
> there is significant objection that we can't resolve.
>
> The one side effect; it's not possible to "FIX" any API until
> we release 2.0.0 - please take some time to look at the new API's
> and think through if they solve our challenges, or if they need
> to be more flexible.
>
IIUC 1.3 allows new functions added, correct?
If that's the case I have something to add by tomorrow.
It's a new apr_pool API allowing to create 'detached'
or 'standalone' pools. Those pools don't have parent
and must be explicitly destroyed.
This is particullary useful for embedding apr in systems
with their own memory management (like Java).
We are doing some really weird tricks in
Tomcat and Mina just to deal with premature and zombie
memory access.
Regards,
--
(TM)