Re: std.serialization: pre-voting review / discussion
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.
Re: std.serialization: pre-voting review / discussion
On Wednesday, 14 August 2013 at 07:40:13 UTC, Jacob Carlborg wrote: 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 You seem to like me to write a comparison to Thrift in the documentation. You have to make the comparison yourself. Wishful thinking aside, they are competitors. The fact that you haven't already done this comparison is unfortunate. I've already done that comparison, tried Orange, and found it wanting. If you don't want everyone else to do the same, you should answer the questions outlined so that it can be positioned appropriately in people's minds. If you'd like examples of how to present design rationale, using contrast for illustration, consider the example of Stroustrup's presentation of C++ features in any of his several books. Contrasting analysis is often essential in describing the history, design and rationale for your work; the "related work" section of any technical publication is required by reviewers. You should provide it if you don't want your work to be dismissed out of hand. Many if not most modern serialization libraries do address transport, and it is critical to the most common use case for serialization: as a developer, I want to move data between two different environments, be they hosts, memories, disk, process, thread, or different languages; so that I can store and process data non-locally and in a non-sequential fashion. For Orange, you can simply say that you have no transport support, and perhaps describe why you don't consider it (e.g. what use case were you designing for?), and that will suffice to answer number three (3). In addition, there are still eight other salient issues. I provided this outline to assist you in describing your work. You'll need to be more specific about where you are confused if you don't understand a particular issue. Ignoring issues won't make them go away, it will just make others ignore and go away from your work.
Re: std.serialization: pre-voting review / discussion
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.
D-thrift package detects regressions since 2.061, where is the regression suite located?
Grrr... Apparently nobody has been testing the D - Apache Thrift bindings since 2.061, and dmd has since accumulated multiple regressions that affect the correctness of the Thrift implementation. I emailed with David N. and he said that this was quite common for each release of dmd, and that while he used to religously evaluate each new dmd release on the Thrift bindings, he had simply not had the time for more recent recents to test each thoroughly. Serialization: this is fundamental. This really isn't the kind of thing that should ever be allowed to break. Hence it really isn't something that should be tested manually. It should be an automatic part of the automatic regression detection test suite. Where is the regression suite for D located, and how can I add to it? There used to be github issue tracking, but I don't see it any more... is it hiding under their new interface perhaps...? Thanks. - glycerine
