Memories are coming back to me ... i think this is why i thought we needed stream.file seperate from stream.url
: So, we have to do something... we could: : a. explicitly set the stream.url.contentType with another param : b. return a FileReader directly (it takes care of charset for you) (a) seems like a good idea no matter what we do As for (b) I'm not sure if i like the idea that we do special things with stream.url if we see that it's afile, if we're going to do something besides delegate to URLConnection, we might as well make it a special param -- i'm okay with that, i like the idea of using a FileReader and letting it worry about the charset, but i'm a little leary of trusting it to be right .... does it trust the OS? what if i'm using a different charset then my OS default? either way we can add a getReader to ContentStream and put a default impl that parses the contentType in a ContentStreamBase ... a FileCotentStream could override getReader to open an explicit FileReader (if we trust it) : (a) may be useful to override a remote content type that is incorrect, : but is kind of a pain for someone specifying a local file (and : probably does not know what content Type it is) : : (b) requires adding getReader() to ContentStream - this would be : useful for direct posted content (the most common case) and for the : local file case. Other cases would construct the reader from the : content type and stream. -Hoss
