I was just playing with possibilities and trying to find ways to improve the API how things are done.
> The interface is designed to > operate in terms of chunks of message data rather than in terms of an > entire message. That's one thing that I'm lacking control through the API actually.. which I'm looking to improve. My application (hornetQ) has the ability to store messages on the disk and send in chunks to the server. Using the current API, I would have to parse the entire message to Proton, and have proton dealing with the chunks. I have tests for instance on sending 1 Gigabyte messages, where the body stays on the disk on the server, while the client streams bytes while receiving, and having flow control holding them. Proton has a big buffer internally, and which actually is not exposing flow control in such way I would stop feeding Proton. as a result this use case would easily cause OMEs from Proton. as I said I was just for now exploring with possibilities. I could send a ReadableBuffer (the new interface from my previous patch) and use a Pool on this buffer to encode my Message. But I stlil lack control on my large messages streaming and flow control. The way things are done now, if i wanted to preserve my large message functionality at the client level (outside of Proton's API), I would need to bypass proton and send Delivery directly without Proton intervention.
