httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apache-2.0/src/lib/apr/include apr.hw
Date Thu, 02 Nov 2000 17:30:13 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Thursday, November 02, 2000 11:15 AM
> 
> On Thu, Nov 02, 2000 at 03:24:25PM -0000, 
> wrowe@locus.apache.org wrote:
> > wrowe       00/11/02 07:24:14
> > 
> >   Log:
> >     The Unicode/WinNT APR patch.  Note that this may even be faster than
> >     MS's internal atow translation that always occurs.  Enabled now by
> >     default.  Warning; it's probable that extended characters in existing
> >     URL's are broken by the patch, since the URL semantic changes.  Also,
> >     launching cgi's, loading modules, etc that use extended characters are
> >     also broken.
> >   
> >     Step 2 is to address the cgi/CreateProcess (spawn) aspects of the patch,
> >     fix dso/LoadModule handling, and accept a Unicode'd httpd.conf file, as
> >     utf-8 is already legal in httpd.conf path specs, but difficult to use.
> 
> Bill, where is the runtime query function to determine how 
> APR was built?

I'll step out of the war and let you and Ryan discuss amoungst yourselves.
I'm +1 for a function to determine build options (all of them).  The compile
time flag is in apr.h.in / apr.hw, along with many more HAS_ macros that
we could query.  But my understanding is that this isn't resolved, some feel
it was discussed on the list and vetoed.  I concur that run-time query is
worthwhile, but let those who disagree bring me up to speed.
 
> As we discussed at ApacheCon, if you alter the semantics of the functions
> (i.e. from native 8-bit encodings to UTF-8 encoding), then you must have a
> runtime query function.

You won't.  That is to say, I don't see us ever flipping between the 
APR_HAS_UNICODE_FS, and not.  To do this on some unixes, perhaps we flip
by volume, but I'm suggesting that Win32 builds will always use this case.

> This allows programs linked against APR to determine
> how it was built (and what semantics it uses for apr_open).

Agreed, somewhat.  It would be a good thing, IMHO.

> Dropping that flag into apr.h is not enough. Consider a Linux 
> distro with a
> couple RPMs which have been built. What happens if they are 
> built against an
> APR with and an APR without the UTF-8 semantics? One of them 
> is going to
> break at install time.

Why?  Please cite an example.

> Another alternative that we discussed at ApacheCon is to have different
> entry points, each with fixed (non-compile-time-changable) semantics. At the
> conference, I was pretty ambivalent about which to choose, but I'm not
> leaning towards two entry point, rather than a single entry point that can
> change semantics on people.

I'm against seperate entry points for this reason.

Unicode OS's (WinNT is one) have a single, native wchar.  char's are just
accedental remnants.  However, IP and other cross platform apps require
something a WHOLE lot more predictable than shifting endianness, and we
don't want multiple code paths anymore.  To APR apps, it's all opaque with
the exception that you can get an APR_EBADCH error from an open call, etc.

APR isn't released, and we don't have some arbitrary mandate to provide
compatibility with APR/Apache 2.0a1.  If we do provide a single entry point,
then we are in shape to accomodate both worlds without multipathed code.

Please provide an example where these file semantics aren't opaque.

> So... this Unicode stuff is incomplete until you have a 
> runtime query (-0) or separate entry points (+1).

I agree it's incomplete, that's why it's in the tree, to move forward :-)

Mime
View raw message