If that is the case then APR_HAS_OTHER_CHILD should not be an option
and should go away completely. All application code should be patched
to handle the return value of APR_ENOTIMPL when these functions are
called. Currently HTTPD #if's out all calls to the other_child
functions based on the APR_HAS_OTHER_CHILD #define. Because of this
fact, swapping out an APR lib with one that supports other child would
not make a difference. It seems that as long as we have #defines like
APR_HAS_OTHER_CHILD, applications will always be dependant on a specific
version or build of APR. Isn't that what we are trying to avoid?
Another observation, why would I ever want to swap out an APR lib
with another that does or doesn't export the symbols? Either my
platform supports that functionality or it doesn't. Which means that as
long as I am running on that platform, all versions of APR, applications
or whatever should always be in sync.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> "William A. Rowe, Jr." <[EMAIL PROTECTED]> Monday, March 03, 2003
1:01:02 PM >>>
Actually we made the mistake of going that way a long time ago.
The problem is that if you compile against one APR with the symbols,
and decide (in order to work around some bug) to plug in another APR
that doesn't export those symbols, you app no longer benefits from
binary compatibility.
So the define tells us that they should/should not work at the time
your application was built. Use that if you like. The stubs will let
your app know that otherchild isn't supported by the installed binary,
which isn't necessarily the APR we built against.
Remember that APR will one day (soon? hopefully?) be it's own beast
installed for everyone's use. That means we shouldn't have too many
behavior changes based on #define symbols, but rather based on what
APR's runtime reports back to us from quering the API or version.
Bill
At 01:15 PM 3/3/2003, Brad Nicholes wrote:
>Further thought. Isn't the point of APR_HAS_OTHER_CHILD so that the
>other_child functions can be safely removed from the platform
>implementation rather than having to define stub functions that only
>return APR_ENOTIMPL?
>
>
>
>Brad Nicholes
>Senior Software Engineer
>Novell, Inc., the leading provider of Net business solutions
>http://www.novell.com
>
>>>> "Brad Nicholes" <[EMAIL PROTECTED]> Monday, March 03, 2003
>11:45:43 AM >>>
>The #if APR_HAS_OTHER_CHILD was removed from around the declaration
of
>the apr_proc_other_child_xxx() procedures in apr_thread_proc.h. Yet
>the
>function apr_proc_other_child_refresh() uses the structure
>apr_other_child_rec_t which has been #if'ed out using
>APR_HAS_OTHER_CHILD. This causes a compiler error on platforms that
>do
>not implement OTHER_CHILD. We need to either put the #if back around
>the function declarations or define apr_other_child_rec_t for all
>platforms that don't implement OTHER_CHILD.
>
>
>
>Brad Nicholes
>Senior Software Engineer
>Novell, Inc., the leading provider of Net business solutions
>http://www.novell.com
