httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 19:39:04 GMT
On Tue, 18 Apr 2000 wrote:
> > Jeff is fixing/improving a documented API. I see nothing wrong with that.
> Except that there is a problem with tackling both problems at the same
> time.  The EBCDIC -> ASCII problem must be solved before we can release
> Apache 2.0, otherwise we regress functions.  The codepage conversion is a
> MUCH bigger problem, and shouldn't be tackled at the same time.  This is
> the same argument you have used for the config tree, so don't tell me it
> is bogus.  The problem should be tackled in pieces, just as I
> suggested.  Start with EBCDIC -> ASCII, and then and only then move on to
> the next piece.

Agreed -- dividing the problem is usually The Right Thing(tm). If Jeff's
current changes don't muck up the EBCDIC work, then there shouldn't be a
problem. He's just adding stuff that wasn't otherwise planned.

That still leaves the EBCDIC work to be done by somebody -- the same state
we are in now. Whether Jeff, Martin, or somebody else does those, then
we're happy. But (hopefully) Jeff's changes will not preclude those future

It's a good thing that you raise the point, so that Jeff can review his
stuff to ensure that the EBCDIC work won't get hosed. It doesn't look like
he is changing any of the prototypes -- just the names.

> > Not at first. From my standpoint, you were saying something entirely
> > different. And bogus: a routine like this cannot a no-op.
> And I've already stated that I was unclear.  And this time (with a
> smiley) I was referring to the comments in the same message.  I disagree
> about this not being able to be a no-op.  defining the macro
> to resolve to APR_ENOTIMPL is a no-op.  It doesn't DO anything, other than
> inform the programmer that nothing was done.  Hence the phrase
> "no-op".  :-)

Heh. :-)

> I will not stand in the way of this (although where the code lives is
> something I will be VERY vociferous about).  In fact, I have already made
> my comments about the code.

No problem there.


Greg Stein,

View raw message