Looking at the documentation and at the code, I can see that the serialization process is like a chain : the user provides data, that is given to a normalizer, which is then given to an encoder, which produces the final output, given back to the user.

I was asked to review #19197, which deals with CSV output. Now when using CSV, it is quite uncommon to serialize only one object : you're probably writing an export script that deals with an amount of data that can be get quite big.

Just like gulp is stream friendly as opposed to grunt, it would be great to have the Serializer be stream friendly, so that you never have to store all your data in memory before outputting it.

Here is how I think the Serializer works at the moment (correct me if I'm wrong):

1. You might be able to provide an iterator (there is a check for \Traversable)
2. But then an array as big as the input will be built and returned for further processing
3. This block of data will most of the time be encoded as a whole, with no foreach involved (with json_encode() or DOMDocument::saveXML()
4. The data is returned as a whole to the user

Thanks to iterators, and with php 5.5, thanks to generators this kind of thing should be possible to design and I think it would make sense to have this kind of feature built-in the Serializer component, especially if you are going to merge #19197 , because it would mean that the Serializer would not care about the size of the input data and perform comparably well with small or huge data.