Avoiding `Binary` format to be based on byte buffers

Just a small side-line note: I do not think it is a good idea to bind the Binary format onto ByteBuffers. Frameworks such as Netty are explicitly built around avoiding ByteBuffer usage as they can be rather performance heavy and uses its own ByteBuf abstraction. It would be of advantage to hooking any form of byte-cosumer / byte-producer into this API.

Also, I do not think that the average user would want to write a binary format to a buffer but rather to a stream. And even when using NIO, I cannot see how an implementor of the API could push or poll bytes asynchronously since the implementation needs to block on the tracer’s inject and extract methods. I therefore think that Binary should rather be some form of callback carrier such as an input or output stream what are at least interfaces that can delegate to a byte byffer if needed without any practical performance impact.

Finally, for the current API, it is not clear to me how the return values of binary are supposed to be used. A ByteBuffer already has internal offsets which are altered during read/write. This only opens a possibility for inconsistencies.

Thanks for clarifying and considering my suggestion.

[raphw]

No worries. I love complaining.

[tedsuo]

That sounds correct, @carlosalberto.