We played a bit with my IO fork and it does not se...

# io

[altavir]

We played a bit with my IO fork and it does not seem to work as well as expected (at least @Zelenyi regularily finds some failing test cases). I like the API, but the problem is that Bytes is not a suted to be a temporary data container due to its volatility. I still do want to be able to copy part of input to a temporary storage object which later could be read from as Input and written to output as a whole. We can certainly do it via ByteArray, but it means additional copy on any such operation.
Instead I am thinking about following thing: we can add additional Binary reading operation into `Input`: By default it reads byte array of given length, but when read from a random-access entity like file or ByteArray it is overwritten by method that does not copy array, but instead creates a Binary which references initial structure and holds offset and size. Thus it could be read and written without additional copy.

[jimn]

https://github.com/jnorthrup/1xam/blob/master/README.md

[jimn]

proto is perhaps a little more relevant in modern times

[jimn]

i wrote a protostuffs IDL client visitor to do 0-copy packed box format serialization against directbytebuffers. https://github.com/0xCopy/prautobeans/blob/master/prautobeans-lib/src/main/java/prauto/io/PackedPayload.java#L53
Proto tools are not bad, but they use heap arrays for structs. that seemed like it adds unneccesary network processing overheads

[jimn]

for pure java you can decompose "Interface" but you may need to annotate a few fields for width.

[jimn]

there are a number of essays surrounding c10k and zero-copy fallacies