httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject [rfc] apreq_env redesign
Date Fri, 24 Oct 2003 15:42:12 GMT

After some googling around about linking on Win32,
I've come to the conclusion that relying on runtime
symbol resolution for the declarations in apreq_env.h
is impossible on Win32 (other non-ELF platforms may
also balk at the current design).  To be 100% portable, 
libapreq2 needs be using function pointers for the 
apreq_env* calls, with a runtime initializer to set 
everything up. 

My plan is similar to the original idea of using a global 
apreq_env vtable:  I plan to put a static vtable pointer in
(a new file named) src/apreq_env.c and let a call to
(the new function) apreq_env_init(&new_vtable_struct) 
reassign the static vtable pointer.  The apreq_env_*
functions will be reimplemented as either macros or
wrapper functions that execute the appropriate vtable
entry.

The big advantage of doing this is that we'll be able to
build a shared apr-only libapreq2.so on all platforms, 
and link the perl glue to *just* that (just as we currently 
do for ELF-based *nix systems).  This should allow the perl
glue to be useful in non-apache-2 environments like CGI.

I'd like to pursue this further, with Randy's help of 
course.  I can start a branch of httpd-apreq-2 cvs if folks 
are unsure that such a change is truly necessary, but I'm 
convinced it is.

-- 
Joe Schaefer


Mime
View raw message