Although this wasn't the entire message of the original - I'm intrigued by the general idea of committing to a line-in-the-sand approach on streaming vs. buffer

Although this wasn't the entire message of the original - I'm intrigued by the general idea of committing to a line-in-the-sand approach on streaming vs. buffering. I've been writing a fair number of file format parsers lately for various audio data, and one of the basic architecture questions that comes up is whether to go for the streamed implementation, when the format allows it, but my use case clearly doesn't need it (and probably won't be subjected to production-grade tests at any time in the near future). Streaming is pretty much universally the more complex option - and when you use a streamed implementation in a buffered fashion, it's wasted engineering effort. Treating data as just data, with the associated ability to copy it around, will always be simpler than maintaining protocol state. So after reading this and reflecting on my own process, I've got a more solid feeling about how to make that call: Support streaming if a certain application demands it. Otherwise, do the simple thing. Do not try to entangle both implementations together, because they have different intentions. Write both independently and refactor the reusable parts instead.