3 ms·
No, it does not collide with "canonical" (colloquial, I'd say) definition of streams, when you think about it. It's only a matter of guarantees on a stream. It
by friendzis 3y ago
No, it does not collide with "canonical" (colloquial, I'd say) definition of streams, when you think about it. It's only a matter of guarantees on a stream. It is not buffered reads/writes that make a stream.
I can take a bunch of XMLs, "stream" them into a TCP socket on one end, feed that socket to "XML stream processing library" on another end and... Watch it blow up, because apparently the only streamy thing about the library is that it can handle asynchronously filled buffer, but will nevertheless blow up if fed anything but a single well-formed xml ¯\_(ツ)_/¯
- gpderetta 3y agoIt is not colloquial when talking about network protocols. From socket(2): SOCK_STREAM Provides sequenced, reliable, two-way, connection-based byte streams. An out-of-band data transmission mechanism may be supported. Not sure what your reference to buffering or async buffers and XML has to do with the topic.
- friendzis 3y agoHere you go, right in the documentation you get that TCP streams are streams with additional qualifiers. Not simply streams. The whole thing we are arguing about: TCP streams are subset of streams. > Not sure what your reference to buffering or async buffers and XML has to do with the topic. An illustrative point for what happens when assumptions from a contrived case are applied on a more relaxed case.