tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <g...@edamame.stinky.com>
Subject MessageBytes / MimeHeaders.java
Date Tue, 29 Aug 2000 19:07:14 GMT
I didn't really follow the proposal.  Could you please give a summary
of why you're changing the API?  Specifically,

 - performance is a good goal but why couldn't it be done behind the
scenes?  (I think the answer is probably "because String is final"
right?)

 - Strings are Unicode; why are they unacceptable for non-ascii
charsets?  Or, why isn't MessageBytes MessageChars instead?  Then the
conversion could/would be done at the last minute after all.

 - MessageBytes seems to have exactly the same API as String; is the
main (only?) reason to use it because we have direct access to its
byte array?

 - Aren't HTTP headers *required* to be plain-ascii?  Any character
encoding has to be done inside the body, not the headers, right?  So
why do you care about supporting non-ascii chars in MimeHeaders.java?
Or do you only use it for performance?

This isn't meant as a challenge -- I trust you had your reasons -- but
just a request for clarification.

Thanks -

 - Alex


>   MessageBytes is now exposed and used instead of Strings. Most methods
>   returning string are removed - if we do the conversion too early (before
>   charset is detected ) we loose all the benefits and optimizations of
>   MessageBytes.
>   
>   As proposed earlier, MessageBytes will gradually replace all Strings
>   - toString() and setString() can be used to provide the old functionality.
>   
>   Also, rewrote the code to enumerate the header names and multi-values.
>   The new code doesn't create GC ( Hashtable, Vector ) and it's probably
>   (more) correct.
>   
>   I think the new code is manageable now, looking forward to review and
>   feedback.
>   
>   ( BTW, the new methods are now getName() and getValue() instead of
>   getHeaderName, etc. The reason is that the same object can be used
>   to store the parameters in an efficient way)
>   
>   This shoud give a significant performance improvment when completed, but the
>   main reasons for doing those changes are:
>   -support for non-ascii charsets
>   -refactoring - better, readable code

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Mime
View raw message