anchor.diff:  | Authors' preferred use case      | distributed  computing | financial / trading | distributed  computing | platforms /  sandboxing | financial / trading | games
   |===============
   
  -NOTE: The Binary YAML format can be automatically converted to YAML without any knowledge of the schema as the messages are self describing.
  -
  -NOTE: You can parse all the expected fields (if any) and then parse any remaining fields. As YAML supports object field "names" or keys, these could be Strings or even Object as keys and values.
  +NOTE: The Binary YAML format can be automatically converted to YAML without any knowledge of the schema, because the messages are self-describing.
  +
  +NOTE: You can parse all the expected fields (if any) and then parse any remaining fields. As YAML supports object field names (or keys), these could be strings or even objects as keys and values.
   
   Based on https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html
   
  
positive.code: 00000030 69 63 65 90 00 00 28 41                          ice···(A 
  ----
  
  Using the RawWire strips away all the meta data to reduce the size of the message, and improve speed. 
  The down side is that we cannot easily see what the message contains.
  
  [souurce, Java]
  ----
          // the same code as for text wire
          wire3.write(() -> "message").text("Hello World")
  
negative.code: 
  - Application configuration. (Using YAML)
  - Data serialization (YAML, binary YAML, JSON, Raw binary data, CSV)
  - Accessing off-heap memory in a thread-safe manner. (Bind to shared off-heap memory)
  - High performance data exchange via binary formats. Only include as much meta data as you need.
  
  == Design
  
  Chronicle Wire uses Chronicle Bytes for bytes manipulation, and Chronicle Core for low level JVM access.
  
  === Why are these concerns conflated?
  
  Often you want to use these interchangeably.
  
  - Configuration includes aliased type information.  This supports easy extension, through adding new classes/versions, and cross-platform through type aliasing.
  - By supporting types, a configuration file can bootstrap itself. You control how the configuration file is decoded. See https://github.com/OpenHFT/Chronicle-Engine/blob/master/demo/src/main/resources/engine.yaml[`engine.yaml`].
  - To send the configuration of a server to a client, or from a client to a server.
  - To store the configuration of a data store in its header.
  - In configuration, to be able to create any object or component.
  - Save a configuration after you have changed it.
  - To be able to share data in memory between processes in a thread-safe manner.
  
  === Features
  
  Chronicle Wire supports a separation of describing what data you want to store and retrieve, and how it should be rendered/parsed. Wire handles a variety of formatting options for a wide range of formats.
  
  A key aim of Chronicle Wire is to support schema changes.  It should make reasonable
      attempts to handle:
  
  * optional fields,
  * fields in a different order,
  * fields that the consumer doesn't expect; optionally parsing them, or ignoring them
  * more or less data than expected; in field-less formats
  * reading a different type to the one written
  * updating fixed-length fields, automatically where possible using a `bound` data structure.
  
  Chronicle Wire will also be efficient in the case where any, or all, of the following are true:
  
  * fields are in the order expected
  * fields are the type expected
  * fields names/numbers are not used
  * self describing types are not needed
  * random access of data values is supported.
  
  Chronicle Wire is designed to make it easy to convert from one wire format to another. For example, you can use fixed width binary data in memory for performance, and variable width or text over the network. Different TCP connections could use different formats.
    
  Chronicle Wire also supports hybrid wire formats.  For example, you can have one format embedded in another.
  
  == Support
  
  This library will require Java 8. Support for `C++` and `C#` is planned.
  
  == Text Formats
  
  The text formats include:
  
  * `YAML` - subset of mapping structures included
  * `JSON` - super set to support serialization
  * `CSV` - super set to support serialization
  * `XML` - planned
  * `FIX` - proposed
  
  Options include:
  
  * field names (e.g. JSON), or field numbers (e.g. FIX)
  * optional fields with default values that can be dropped
  * zero copy access to fields - planned
  * thread safe operations in text - planned
  
  To support wire format discovery, the first byte should be in the `ASCII` range; adding an `ASCII` whitespace if needed.
      
  == Binary Formats
  
  The binary formats include:
  
  * binary YAML.
  * delta compressing Binary YAML. This is a Chronicle Wire Enterprise feature
  * typed data without fields
  * raw untyped fieldless data
  * BSON (Binary JSON) - planned
  
  Options for Binary format:
  
  * field names or field numbers
  * variable width
  * optional fields with a default value can be dropped
  * fixed width data with zero copy support
  * thread-safe operations
  
  Note: Chronicle Wire supports debug/transparent combinations like self describing data with zero copy support.
  
  To support wire format discovery, the first bytes should have the top-bit set.
  
  == Using Wire
  
  === Simple use case.
  
  First you need to have a buffer to write to.  This can be a `byte[]`, a `ByteBuffer`, off-heap memory, or even an address and length that you have obtained from some other library.
  
  [source, Java]
  ----
  // Bytes which wraps a ByteBuffer which is resized as needed.
  Bytes<ByteBuffer> bytes = Bytes.elasticByteBuffer();
  