+1 for allowing to register message factories to deal with different content types. The content type used in the protocol with the (message or basic) class can then carry this content type to provide a hint to the message consumer as to how to treat the message.
If the consumer can understand the content type it's fine or else they can just treat is as binary data. Rajith On 4/9/07, Robert Greig <[EMAIL PROTECTED]> wrote:
On 09/04/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote: > Not only when consuming messages, but also when creating them. Yes, it > appears the message factory mechanism was intented to do this to a point > (though it seems the upper level public APIs didn't quite keep this in > mind). Yes, perhaps this is a good opportunity to address that. > That said, from a user's perspective, I'd quite prefer to be able to simply > get a message and decide to interpret it *after* the fact. One particular > advantage of this is that it doesn't limit you to interpret a message a > single way right at the moment the message was received. With the current > mechanism, once the message factory decided the message was text you can't > really look at the message any other way. Ah yes, looking at the current text message it doesn't really provide a reasonable way to extract the underlying bytes. You should perhaps override the mapping for the text/plain MIME type to be just a bytes message. Of course if you are just going to as a first step turn the message into a String then there isn't any advantage. RG
