httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <ra...@theoryx5.uwinnipeg.ca>
Subject Re: [rfc] apreq_env redesign
Date Sat, 25 Oct 2003 05:40:39 GMT
On Fri, 24 Oct 2003, Joe Schaefer wrote:

>
> 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.

I'm slightly biased :), but this sounds great ...

-- 
best regards,
randy

Mime
View raw message