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/
