httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 16:17:55 GMT

> > return APR_ENOTIMPL.  That is how we return that this is not implemented
> > in APR.
> 
> In defense of Jeff... Ryan: you were totally unclear on this. You said
> make them a no-op. Not return APR_ENOTIMPL.
> 
> Jeff was entirely right when he said that they cannot be no-ops.

Yep.  I was unclear.

> > No, I'm talking APR through Apache.  There is a difference.  APR v1.0 is
> > being implemented for Apache.  We'll add more once 1.0 is out the door.  I
> > stated that having APR's iconv do EBCDIC->ASCII for 1.0 is "the right
> > thing", but anymore than that is wasted time/effort.  In later versions of
> > APR we can finish the work.  The fact is, not all Unix's have iconv.  This
> > is a problem.  However, we can easily re-implement this for all platforms,
> > but I suggest not trying to do this for v1.0.  Punt it to the next
> > version.
> 
> Bogus argument. Jeff has the time and inclincation to do this work. You
> cannot tell him "don't do that" or that the time is wasted. He doesn't
> feel the same.
> 
> Ryan: you initially put those functions in on the fly, without much
> thought towards them. I don't see how you can now say "they've been in
> there for three months, so you can't change the function names" or that
> they should remain in their "quick solution" state.

I never said the names were put in with no thought.  The functions, what
they do, and what they are called were hashed out through a couple of
days.  It was in a meeting with 390 and 400 developers that this stuff was
hashed out.  I then sent an e-mail to I believe Martin to get the stuff we
decided on approved for BS2000.  Just because the def's and macros were a
hack doesn't mean the design was.  

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

> 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".  :-)

> btw, +1 on Jeff's changes.

I am +1 on the spirit of Jeff's changes, but -0 on how they were
implemented.  I have given Jeff my comments, and as far as I can see, he
explained where I was unclear (I clarified), and now he is addressing my
concerns.  When I see the new code, I expect to be +1 for the changes.

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.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message