You are right that my current approach does not necessarily handle all possible cases. It does (awkwardly) handle a simple request/response scenario (http, zeromq, rabbitmq, etc) where requests are received in **full** and passed along to a processor whose job is to generate a response in **full**. Other language implementations have this simple in-memory-only pathway that allows for decoupling of byte transport and thrift processors. I would argue that one of the core capabilities a library has to demonstrate is processing of raw byte arrays. Handling partial payloads for streaming applications should be another core capability, and I think both of them could be done using a single approach where raw bytes are fed on one end and raw responses are received back via callbacks. In classical gen_server fashion the thrift data handling process would never end, always waiting to ingest more bytes. On complete-payload-detected it would synchronously processes it, fire a raw response to a registered listener/process, and continue ingesting more bytes. Full and chunked requests would then be equally handled, and transports and processors would be decoupled better. Not a quick fix though.
[ Full content available at: https://github.com/apache/thrift/pull/1552 ] This message was relayed via gitbox.apache.org for [email protected]
