How about changing Method not to MimeType but rather to ContentType?
A construct I use *very* often in my HTML files is the following:
<meta http-equiv='content-type' contents='text/html; charset=x-sjis'>
Which would correspond to an equivalent response line from a web
server or a header line in an email message:
Content-Type: text/html; charset="x-sjis"
Then the ContentType could be the one used to specify the encoding
of the output stream. Which brings me back to my binary vs.
character serializer comment...
Clearly, in Java, OutputStream is for binary output and Writer is
for character output. However, what's implied is that the program
has constructed the appropriate writer that converts the Unicode
characters to the appropriate byte sequences in that encoding. So
a Writer object is really writing to an OutputStream.
But by changing character serializers to only support Writer, it
would appear that we're putting the onus on the programmer to
both specify the charset for the encoding type (so that any
reference to the charset in the output is correct -- e.g. the
XML encoding names, IANA, are *not* the same as the Java encoding
names) *and* create an output writer with the appropriate Java
encoding! However, I think that we can work through this by
providing a convenience mapping that creates the appropriate
writer from a given output stream. Here's a quick example:
public class ContentType {
// Data
protected String type;
protected String charset;
// Constructors
public ContentType(String type, String charset) {
this.type = type;
this.charset = charset;
}
// Public methods
public Writer createWriter(OutputStream out)
throws UnsupportedEncodingException {
String javaEncoding = /* do mapping on charset */;
return new OutputStreamWriter(out, javaEncoding);
}
// ... etc ...
}
What do you think?
Or maybe a static method would be better? Hmmm... I'm just
brainstorming here. I'd really like to hear other people's
opinions.
(I noticed that Sun's JavaMail extension has something
similar: javax.mail.internet.ContentType)
--
Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED]
