std.serialization: pre-voting review / discussion

[BS]

On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote:
> On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote:
>> On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
>>> Wishful thinking aside, they are competitors.
>>
>> They are not. `std.serialization` does not and should not 
>> compete in Thrift domain.
>
> Huh? Do you know what thrift does? Summary: Everything that
> Orange/std.serialization does and more. To the point: Thrift
> provides data versioning, std.serialization does not. In my 
> book:
> end of story, game over. Thrift is preffered choice. If you
> are going to standardize something, standardize the Thrift
> bindings so that the compiler doesn't introduce regressions
> that break them, like happened from dmd 2.062 - present.
>
> You don't provide any rationale for your assertion, so I can't
> really respond more constructively until you do. Please
> familiarize yourself with D's Thrift bindings, which work well
> with dmd 2.061. Then provide a rationale for your conjecture.

I agree built in version support is important.

As for your other issues you mention:

a) do one thing, do it well.
b) modular is better than monolithic.
c) std.serialization is for serialization, no more no less.
d) Thrift is for scalable cross-language services development.
(and much more http://thrift.apache.org/)

Just because Thrift can serialize classes/structs doesn't mean 
std.serialization  should support RPC services or transport of 
serialized data.

I'd rather that was left for a separate module (or two or three) 
built on top of std.serialization.