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.
