ilya-stromberg wrote: >>> The serialized data is returned as an array, so that is >>> compatible with >>> the range interface, it just won't be lazy. >> >> This seems like a major limitation. (Disclaimer: I haven't read >> the documentation yet.) >> >> Andrei > > Shall we fix it before accept the std.serialization? > > For example, if I have 10GB of data and 16GB operating memory, I > can't use std.serialization. It saves all my data into string > into operating memory, so I haven't got enough memory to save > data in file. It's currently limited by std.xml. > > In other hand, std.serialization can help in many other cases if > I have enough memory to store copy of my data. > > As I can see, we have a few options: > - accept std.serialization as is. If users can't use > std.serialization due memory limitation, they should find another > way. > - hold std.serialization until we will have new std.xml module > with support of range/file input/output. Users should use Orange > if they need std.serialization right now. > - hold std.serialization until we will have binary archive for > serialization with support of range/file input/output. Users > should use Orange if they need std.serialization right now. > - use another xml library, for example from Tango.
My opinion is - accept it as it is (if it's not completely broken). I recently needed some way to serialize a data structure (in order by save the state of the app and restore it later) and was quite disappointed there is nothing like that in Phobos. Although XML is not necessarily well suited to my particular use case, it's still better than nothing. Binary archive would be a great plus, but allow me to point out that current state of affairs (std.serialization being in a pre-accepted state for a long time AFAIK) is probably the worst state we might have - on the one hand I would not use third party libs, because std.serialization is just around the corner, on the other I don't have std.serialization distributed with the compiler yet. Also binary archive is an extension, not a change, so I don't see any reason why it could not be added later (because it would be backward compatible). -- Marek Janukowicz
