Request for review - std.serialization (orange)

[Francois Chabot]

On Monday, 17 June 2013 at 20:59:31 UTC, Jacob Carlborg wrote:
> On 2013-06-17 16:39, Francois Chabot wrote:
>
>> I will grant that making Orange part of Phobos will alleviate 
>> the
>> project bloat issue, which is a huge deal. But as it stands, 
>> to me, it
>> only handles a subset of what std.serialization should.
>
> So what would you like it to handle? I assume you want a binary 
> archive and you want faster serialization? You are free to add 
> enhancement requests to the github project and comment in the 
> official review thread.

Well, the main thing that I want on my end is a O(1) memory 
footprint when dealing with hierarchical data with no 
cross-references. Even better would be that serialization being a 
lazy input range that can be easily piped into something like 
Walter's std.compress. I guess I could log an enhancement request 
to that effect, but I kinda felt that this was beyond the scope 
of Orange. It has a clear serialize, then deal with the data 
design. What I need really goes against the grain here.

> The thing is with Orange is that it's possible to add new 
> archive types. If Orange gets accepted as std.serialization we 
> could later add a binary archive.

Once again, the sticking point is not the serialization format, 
but the delivery method of said data.

Hmmm, come to think of it, running Orange in a fiber with a 
special archive type and wrapping the whole thing in a range 
could work. However, I'm not familiar enough with how 
aggressively Orange caches potential references to know if it 
would work. Also, due to the polymorphic nature of archives, 
archive types with partial serialization support would be a pain, 
as they would generate runtime errors, not compile-time.

> Do you want to stop std.serialization just because of it not 
> having a binary archive? Not having a binary archive doesn't 
> make the XML archive useless.

No! no no no. I just feel that Orange handles a big piece of the 
serialization puzzle, but that there's a lot more to it.