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.