Message Classes Modification Proposal

[Tomas Restrepo <to...@devdeo.com>]

Based on our previous discussion on the rationale for the design of the
Message classes in the Qpid client API (this goes for both the java and .net
clients at least), I'd like to propose a few improvements to the message
classes in Qpid.

My proposal is actually fairly modest, so I think it shouldn't have long
reaching effects into the API except [hopefully] adding a bit of usability
to it. So here are the changes I propose:

1- Create a new overload of the CreateMessage() to the AMQSession/AmqChannel
classes that takes the MIME type of the message to create. It would simply
pass that value to the underlying message factory registry to create an
instance of the proper message class.

2- Add a new method to the Session/IChannel interfaces (and corresponding
implementations) to register a new message factory to a new MIME type (maybe
add one to unregister a factory as well?)

3- Preserve the MIME type used to create the message through the message
factory registry. Right now, the mime type requested is passed to the
registry which uses the associated factory. However, the mime type requestes
is not passed on to the factory and instead each message class initializes
the MimeType property to a default value. So, for example, if you create a
message with the type "text/xml", the resulting message object will still
return "text/plain" from getMimeType()

4- Give all message classes (or at least the basics) the ability to read or
replace the underlying byte buffer representing the body of the message
through methods in Message/IMesssage or friends.

Any comments?

Tomas Restrepo
http://www.winterdom.com/weblog/