apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PROPOSAL] cgi_exec_info_t: detached & addrspace fields combined
Date Mon, 28 Jun 2004 16:08:34 GMT
   Joe is correct.  The interface that we have now in APR HEAD is
sufficient to solve the problem.  If we released APR 1.0 now the same
solution would exist in APR 1.0 and 1.1.  The real issue is what to do
about APR 0.9 since it will continue to live as long as applications
like httpd 2.0 is dependent on it.  The way I see it we have a few
options.

1. Do nothing which includes *not* backporting the log.c patch (yes, I
know.  This is an issue for the dev@httpd list)
2. Backport the apr_procattr_addrspace_set() interface currently in APR
HEAD and make a call on wheither or not it deserves an MMN bump.
3. Adopt Jean-Jacques's proposal for both APR 1.0 and 0.9.
4. Implement the apr_procattr_detach_set() overloading solution in 0.9
and live with the difference between 0.9 and 1.0.

I would rather see option #2 since it seems to be the right thing to do
for APR.  But we still have to deal with that nasty MMN bump issue.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> "David Reid" <david@jetnet.co.uk> Monday, June 28, 2004 5:23:03 AM
>>>
> OK, the apr_procattr_addrspace_set() interface is sufficient to
solve
> this problem, right?  And there's no issue with back-porting that to
the
> APR 0.9 branch?  The only issue is how to use that interface from
> mod_cgi/the Netware MPM without requiring an httpd major MMN bump? 
So
> why not just overload the 'detached' field in cgi_exec_info_t inside
> mod_cgi/Netware MPM?  That's should cause too much damange.
>
> -1 on overloading apr_procattr_detach_set() to do this, that's bad
API
> design, and uglifying the APR API just to satisfy an httpd binary
compat
> requirement just seems very wrong.

It does.

> If the interface in APR HEAD is sufficient to solve the problem
there's
> no reason why this is an APR 1.0 showstopper either.

Right.

The issue is more that if we *don't* include an api change that is
subsequently back-ported to apr 0.9 then we will have functionality in
apr
0.9 and 1.1 but not in 1.0 - which just seems plain wrong and dumb...
That's
why I stopped the process.

david


Mime
View raw message