Hi Everyone, I've been working on some new stuff on top of Qpid lately and I'm running into a few limitations in the design for the message classes (i.e. IMessage and friends). So I'd thought I might as well solicit some input on the topic. This is a bit long, so bear with me :)
Could someone explain to me the overall rationale for the message classes design? In particular, just what exactly should the relationship be between the different message classes (i.e. BytesMessage, TextMessage and friends). Currently the design is very similar in both the .NET and Java clients, though the Java one has a few more message classes (stream, object, map). Here are some of the topics I'm a bit confused about: - It would appear that the classes have been designed as parallel structures. That is, it seems like either you have one or another class of message, and the system uses the message MimeType to distinguish each class during send/receive. At some point, it seems to me like you may want to treat one message class as another arbitrary class (I'll explain below why). - It seems like the MimeType system chosen is closed (probably because of the above): The MimeType is set only during message creation and cannot be changed, and it seems like it is expected that only a handful of types are treated in a special manner (e.g. text/xml -> ITextMessage). - It's not clear what the ContentType property does (at least to me... it's unimplemented in the .NET client and seems to be used for something unintuitive in the Java client). Basically, here's my scenario: I'm working on a connector on top of the Qpid.NET client that will send and receive messages. Most messages will be text-based messages which might contain plain XML or SOAP xml messages, or potentially arbitrary binary or encoded contents (like a large stream message or an MTOM encoded SOAP envelope). The second issue is that message encoding, in all cases (even for plain xml messages) is controlled a layer above my connector by some platform code. That means that in general, I can't use the Qpid TextMessage class, because it handles encoding itself, so instead I have to treat, on my end, all messages as if they were arbitrary binary messages whose content is opaque to my connector. That would mean using a BytesMessage or a stream message type of sorts (which we don't have yet in Qpid.NET). More important, however, is that for the general case (xml, text and soap messages) I don't want to hamper interoperability and make it hard for consumers (which might be in a different language, like java or cpp clients) to receive and interpret the messages I send and the other way around. If I sent all messages as QpidBytesMessage, I'd need to have special code in the other consumer to interpret the message as text content. This is in part because of how the MIME type in qpid works at the time (at least as I understand it from reading the code) and how it is used to decide which message class is used. So, in my connector, from the publisher perspective, what I'd like to be able to do is to create a "binary message" (i.e. a bytes message of sort) and configure it exactly as I want so that it can be seen at the other end as a text message (so configure things like mime type and encoding manually to suit my content). Likewise, from the consumer perspective, I'd really like the ability to reinterpret a message using a different structure. For example, the current QPID implementation doesn't know anything about MIME type "application/soap+xml" so if it received a message with this content type, it would interpret it as BytesMessage, making it harder to consume. So as a consumer, what I'd like is the ability to say: "Let me treat this arbitrary message I received as a Text Message so that I get the nice text message interface to it even though you think it contains something different". Does it make sense? (Note, also, that the MIME type system in qpid is being handled in a pretty low level fashion now. In fact, channels or sessions don't expose a way to create an message for an arbitrary MIME type). Any advice or recommendations? Does this sound like a useful use case in the general sense? Tomas Restrepo http://www.winterdom.com/weblog/
