Justin Erenkrantz wrote:
>
> On Mon, Jul 02, 2001 at 06:09:44PM +0200, GOMEZ Henri wrote:
> > >Realistically though, APR is fairly stable API-wise. There *are*
> > >going to be some minor changes and tweaks along the way. But, they
> > >should all be for the better (like the util_date migration).
> >
> > I'm confident that APR is stable, but what we need is a RELEASE.
>
> Hmm, I wonder if we should do a T&R with APR to give a "release"
> that is separate from httpd-2.0. I don't see any reason why we
> couldn't do this. I just have no clue how to do the T&R. My
> understanding is that anyone with commit privs can do that.
> I'll look into it though.
To make things more easy we could tag when http-2.0 releases.
>
> BUT, I think that the precedent with the APR-using projects is to
> require a source checkout. Subversion and httpd-2.0 both require
> the current CVS version of APR. This allows APR to not have to
> maintain backward compatibility with "previous" releases (not
> that we would anyway).
>
> > >And, I guess, my point is that we should start that transition now.
> > >Start to write a mod_jk that is built around APR. By the time
> > >that is done, Apache 2.0 may even be release candidate. Or not.
> >
> > What about working an APR wrapper ? ie something which wrap OS calls
> > to APR or native calls ? And make mod_jk call wrapper functions ?
>
> I think that defeats the purpose of APR. If APR isn't doing it right,
> then APR needs to be fixed. APR should definitely support any platforms
> that you are concerned about (i.e. Win32, etc.). Which, of course,
> means that httpd-2.0 will run on those platforms as well.
>
> The idea is that APR would better support these platforms than rewriting
> the same code in mod_jk. And, ideally, if you build around APR, you
> will simplify the build process because APR will figure out all the OS
> trickiness for you.
How could one write a wrapper for the following?:
+++
-int jk_open_socket(struct sockaddr_in *addr,
+apr_status_t jk_open_socket(apr_socket_t **new, apr_sockaddr_t *addr,
int ndelay,
- jk_logger_t *l)
+ jk_logger_t *l, apr_pool_t *cont)
{
- int sock;
+ apr_status_t ret;
jk_log(l, JK_LOG_DEBUG, "Into jk_open_socket\n");
- sock = socket(AF_INET, SOCK_STREAM, 0);
- if(sock > -1) {
- int ret;
+ ret = apr_socket_create(new,AF_UNSPEC,0,cont);
+ if (ret) {
/* Tries to connect to JServ (continues trying while error is EINTR) */
do {
+++
jk_open_socket is in jk_connect.c and the above is a diff of "APRized" and
actual jk_open_socket().
Well I am just trying to show I cannot see how to write a wrapper for that...
>
> > But even APR will only cover OS calls, and didn't solve the problems of
> > linking with web-server differents from Apache (IIS/iPlanet/Domino...)
>
> Correct, but the core jk components could still be built around APR.
> And, I imagine that the problem of other webservers has to do more with
> their specific OS than the web server (i.e. linking in APR).
>
> And, hopefully, I'll have time at some point to actually back up what I
> am saying with code. I've just got a bazillion other things on my plate
> right now. =) -- justin aka "APR evangelist"
