6 ms·

I used that approach for my minecraft protocol parsing library (https://github.com/dividuum/fastmc https://github.com/dividuum/fastmc). It's indeed very useful

I used that approach for my minecraft protocol parsing library (https://github.com/dividuum/fastmc https://github.com/dividuum/fastmc). It's indeed very useful to decouple parsing a protocol from the underlying transport. I used my library both for socket communication as well as to read and write files. I'd love to see more libraries implemented that way. So thanks for posting that link. I imagine it might be difficult sometimes depending on the protocol. IIRC TLS might sometimes require writes while reading.

Lukasa 10y ago
It turns out TLS isn't that bad. OpenSSL exposes a "memory BIO", which is basically exactly this. You send in writes, and then emit data when you can, and in the meantime it buffers. It's a bit more limited than that, but generally speaking it's not too bad.
- JoshTriplett 10y ago
  I assume you handle decompression the same way? Feed in data, and the decompressor emits data when it can?
oxymoron 10y ago
On the topic of IO. I'm actually a fan of java.io.Reader/Writer and java.io.InputStream/OutputStream. It seems to me that most java protocols and parsers are quite composable by default due to these simple little abstractions. Granted, they might not be a good fit for async IO, but I'd still argue that they've held up quite well during the past fifteen years. I'll go out on a limb and claim that standard C++ IO haven't worked out quite as well, although it might just be my skip-the-oo-and-template-everything skepticism. Rust seems closer to java, although I feel like the Jury's still out. I'm not a enthusiastic of doing everything asynchronously as in Node. Haskell does seem to get the composability right. Python has some of javas thinking through a standard convention on the method names for reading and writing (an interface!), but it seems common with departures from those simple rules when people get creative. From that perspective, an initiative like this is quite understandable and convenient. Nevertheless, I don't seem to feel the need in the same way in certain other languages.
- paulddraper 10y ago
  A little off-topic but IMO one of the more unfortunate decisions by Java was Reader/Writer and InputStream/OutputStream, instead of CharReader/CharWriter and ByteReader/ByteWriter (or similar).

Lukasa 10y ago

It turns out TLS isn't that bad. OpenSSL exposes a "memory BIO", which is basically exactly this. You send in writes, and then emit data when you can, and in the meantime it buffers. It's a bit more limited than that, but generally speaking it's not too bad.

JoshTriplett 10y ago
I assume you handle decompression the same way? Feed in data, and the decompressor emits data when it can?

oxymoron 10y ago

On the topic of IO. I'm actually a fan of java.io.Reader/Writer and java.io.InputStream/OutputStream. It seems to me that most java protocols and parsers are quite composable by default due to these simple little abstractions. Granted, they might not be a good fit for async IO, but I'd still argue that they've held up quite well during the past fifteen years. I'll go out on a limb and claim that standard C++ IO haven't worked out quite as well, although it might just be my skip-the-oo-and-template-everything skepticism. Rust seems closer to java, although I feel like the Jury's still out. I'm not a enthusiastic of doing everything asynchronously as in Node. Haskell does seem to get the composability right. Python has some of javas thinking through a standard convention on the method names for reading and writing (an interface!), but it seems common with departures from those simple rules when people get creative. From that perspective, an initiative like this is quite understandable and convenient. Nevertheless, I don't seem to feel the need in the same way in certain other languages.

paulddraper 10y ago
A little off-topic but IMO one of the more unfortunate decisions by Java was Reader/Writer and InputStream/OutputStream, instead of CharReader/CharWriter and ByteReader/ByteWriter (or similar).