On Mon, 2007-08-20 at 10:42 +0100, Rupert Smith wrote: > //Option3 - can use it with any message size, recomended for large messages > public void messageTransfer(String destination, short confirmMode, > short acquireMode); > public void headers(Struct... headers); > public void data(byte[] data); > public void data(ByteBuffer buf); > public void data(String str); > public void endData(); > > as if this is an important innovation. But then JMS has the StreamMessage > class, that provides this capability.
Sorry but I must disagree with this statement as a JMS streamMessage is just a convenient way of building a message that is eventually sent as if. What you are describing would be equivalent to a JMS way of handling large messages, that is to say splitting the message and sending small batches to the broker. > There is a difference, and that is > that in the example, the transfer comes before the appending of data, > followed by an explicit end to terminate. Does this mean we are doing real > streaming over the protocol 'message class'? Again, I am not clear on this, > 0-8 had separate 'message' and 'stream' classes, does 'message' in 0-10 now > covers streaming too? If so, then it looks to me like this would be a useful > JMS API extension, that would sit side by side with the JMS implementation, > rather than as a lower-level that sits beneath it. In a similar way to how > the current 0-8 implementation provides horizontal extension of JMS for AMQP > specific features. > This proposed API lets me bind exchanges, about the only thing it offers > that JMS does not already cover. I think that the real debate that is going on is whether we want to expose the AMQP protocol as it or if we want to provide a slightly higher level API that provides few convenient features. I like what Rupert is proposing but it may be too low level. Rupert you are saying that the current API does not expose the AMQP ping mechanism. Is that all? Can you provide an exhaustive list of the AMQP features that are not exposed? Arnaud
