std.serialization: pre-voting review / discussion

[glycerine]

On Tuesday, 13 August 2013 at 15:12:40 UTC, Dicebot wrote:
> On Tuesday, 13 August 2013 at 15:04:38 UTC, Jacob Carlborg 
> wrote:
>> I worked quite hard with the documentation. There are code 
>> examples here as well, I just don't know where to put them in 
>> Phobos:
>>
>> https://github.com/jacob-carlborg/orange/wiki/_pages

I'm included to prefer the Thrift bindings over Orange since I 
need binary compression and type safety (XML??? yikes), 
inter-language operability, and most essentially, data versioning.

Nonetheless, in order to make a realistic comparison and 
evaulation, I need much more of the theory of operation, and a 
description of the Orange design.  I appreciate that you worked 
hard with the documentation.  But most of the essential 
description is missing.

Here is an outline of serialization tradeoffs and architectural 
issues that should be discussed in the documentation.

1. Interface Definition Language (IDL): required or not? If not, 
how do know the details of what to serialize. If not, how do you 
handle/support data versioning? If not, how do you interoperate 
without another language? If yes, which types are supported and 
what is the syntax and grammar of the IDL?

2. Is the serialized format independently de-marshallable, or is 
meta information required in addition?

3. Which transports if any, are integrated/supported?  Memory 
buffer, file descriptor, framed, zero-copy, socket, SSL support, 
JSON, etc.

4. Are service definitions supported (methods on objects or 
functions)? Are they versioned?

5. How compatible is the format with other languages?

6. How compact is the encoding?

7. How fast is to marshal and unMarshal?  What tradeoffs were 
made.

8. Is there a debug encoding, text that is human readable?

9. To emphasize the important point of the first item again: data 
versioning: how do you upgrade your cluster when a data 
definition changes?  If your serailization format requires 
simultaneous downtime for the entire cluster instead of 
supporting incremental upgrade, I'd say your architecture is 
seriously antiquated.