std.serialization: pre-voting review / discussion

[Jacob Carlborg]

On 2013-08-14 00:54, glycerine wrote:

> 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.

It seems like we have a different meaning of "essential". I have 
documented the package for what it is, not for what it's not. It's a 
package for serialization, not a RCP or network package. SSL support 
doesn't make sense, it's like asking "Does std.algorithm.map has SSL 
support?".

You seem to like me to write a comparison to Thrift in the 
documentation. You have to make the comparison yourself.

> 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.

Many of these questions doesn't even make sense, as I stated above.

-- 
/Jacob Carlborg