httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: Apache 2.0 alpha. (again) :)
Date Tue, 21 Mar 2000 03:11:36 GMT
> From: Life is hard, and then you die. []
> Sent: Monday, March 20, 2000 3:18 AM
> One day, William A. Rowe, Jr. wrote:
> > 
> > It looks good from here, I will be happy to offer the 
> changes to Win32;
> [snip]
> > > 1) move ap/ap_sha1.c to lib/apr/lib/apr_sha1.c and 
> include/ap_sha1.h
> > >    to lib/apr/include/apr_sha1.h; adjust various defines and types
> > >    in the process.
> > > 2) move ap/ap_base64 to lib/apr/lib/apr_base64 and ap_base64*
> > > declarations
> > >    from include/ap.h to lib/apr/include/apr_base64.h; 
> adjust various
> > >    defines and types in the process.
> > > 3) Update lib/apr/lib/apr_md5.c and 
> lib/apr/include/apr_md5.h to use
> > >    apr types and defines
> > > 4) move ap_MD5Encode and ap_validate_password from
> > > lib/apr/lib/apr_md5.c
> > >    and ap_sha1_base64 from lib/apr/lib/apr_sha1.c to new
> > >    lib/apr/lib/apr_checkpass.c. ap_MD5Encode and 
> ap_sha1_base64 should
> > >    probably be renamed to something more explanatory and 
> consistent,
> > >    such as ap_md5_password and ap_sha1_password).
> Um, Manoj and Greg expressed some aversion to having things 
> like base64 and sha1 go into apr.

Hmmm... I see what you mean ;~}

> Ryan and William (I guess) are for it. Any 
> other opinions?

Well... we could split this down the middle.  If there should be
a seperate package under Un*x for ap.lib vs aprlib, then lets
go that route.  In the interim, we can define the Win32 apaprlib
as a combined .dll of their functionality.  The two platforms
here might diverge in their interest, that doesn't mean we 
can't wrap up two solutions for the same issue.

Of course, this implies seperate ap and apr source/header trees
and other deliniations, and I suppose if I'm defining EXPORT tags
I will maintain both AP_EXPORT* and APR_EXPORT* definitions.

Since Win32 is a 64K boundry environment, I see little reason to
gobble an extra chunk for a binary the size of the ap.lib code.
Since the binary is platform dependant, I'm wondering if any other
Win32 folks have a take on this either way.

I do have an issue, though, that we aught to move the ap branch
under src/lib/ap instead, and follow the tree structure of apr.
If we are going to maintain multiple libraries, let's at least
keep some consistency and keep down the learning curve for new
contributors (welcome Brian!)


View raw message