anchor.diff:     long id = counter.getAndAdd(1);
   ----
   
  -Other types such as 32 bit integer values and an array of 64-bit integer values are supported.
  +Other types are supported; for example,32-bit integer values, and an array of 64-bit integer values.
       
   == Compression Options
   
   * no compression
  -* Snappy compression (planned)
  -* LZW compression (planned)
  +* Snappy compression - planned
  +* LZW compression - planned
   
   == Bytes options
   
   Wire is built on top of the Bytes library, however Bytes in turn can wrap
   
  -* ByteBuffer - heap and direct
  -* byte\[\] (via ByteBuffer)
  +* `ByteBuffer` - heap and direct
  +* `byte\[\]` - using `ByteBuffer`
   * raw memory addresses.
   
  -== Uses
  -
  -Wire will be used for:
  -
  -* file headers.
  -* TCP connection headers where the optimal Wire format actually used can be negotiated.
  -* message/excerpt contents.
  -* the next version of Chronicle Queue.
  +
  +== Handling instance classes of an unknown type
  +
  +This feature allows Chronicle Wire to de-serialize, manipulate, and serialize an instance class of an unknown type.
  +
  +If the type is unknown at runtime, a proxy is created; assuming that the required type is an interface.
  +
  +When the tuple is serialized, it will be give the same type as when it was deserialized, even if that class is not available.
  +
  +Methods following our `getter`/`setter` convention will be treated as `getters` and `setters`.
  +
  +This feature is needed for a service that stores and passes on data, for classes it might not have in its class path.
  +
  +NOTE: This is not garbage collection free, but if the volume is low, this may be easier to work with.
  +
  +NOTE: This only works when the expected type is not a class.
  +
  +=== Example
  +
  +[source, Java]
  +----
  +@Test
  +public void unknownType() throws NoSuchFieldException {
  +    Marshallable marshallable = Wires.tupleFor(Marshallable.class, "UnknownType");
  +    marshallable.setField("one", 1);
  +    marshallable.setField("two", 2.2);
  +    marshallable.setField("three", "three");
  +    String toString = marshallable.toString();
  +    assertEquals("!UnknownType {\n" +
  +            "  one: !int 1,\n" +
  +            "  two: 2.2,\n" +
  +            "  three: three\n" +
  +            "}\n", toString);
  +    Object o = Marshallable.fromString(toString);
  +    assertEquals(toString, o.toString());
  +}
  +
  +@Test
  +public void unknownType2() {
  +    String text = "!FourValues {\n" +
  +            "  string: Hello,\n" +
  +            "  num: 123,\n" +
  +            "  big: 1e6,\n" +
  +            "  also: extra\n" +
  +            "}\n";
  +    ThreeValues tv = Marshallable.fromString(ThreeValues.class, text);
  +    assertEquals(text, tv.toString());
  +    assertEquals("Hello", tv.string());
  +    tv.string("Hello World");
  +    assertEquals("Hello World", tv.string());
  +
  +    assertEquals(123, tv.num());
  +    tv.num(1234);
  +    assertEquals(1234, tv.num());
  +
  +    assertEquals(1e6, tv.big(), 0.0);
  +    tv.big(0.128);
  +    assertEquals(0.128, tv.big(), 0.0);
  +
  +    assertEquals("!FourValues {\n" +
  +            "  string: Hello World,\n" +
  +            "  num: !int 1234,\n" +
  +            "  big: 0.128,\n" +
  +            "  also: extra\n" +
  +            "}\n", tv.toString());
  +
  +}
  +
  +interface ThreeValues {
  +    ThreeValues string(String s);
  +    String string();
  +
  +    ThreeValues num(int n);
  +    int num();
  +
  +    ThreeValues big(double d);
  +    double big();
  +}
  +----
  +
  +=== Example with `MethodReaders`
  +
  +[source, Java]
  +----
  +@Test
  +public void testUnknownClass() {
  +    Wire wire2 = new TextWire(Bytes.elasticHeapByteBuffer(256));
  +    MRTListener writer2 = wire2.methodWriter(MRTListener.class);
  +
  +    String text = "top: !UnknownClass {\n" +
  +            "  one: 1,\n" +
  +            "  two: 2.2,\n" +
  +            "  three: words\n" +
  +            "}\n" +
  +            "---\n" +
  +            "top: {\n" +
  +            "  one: 11,\n" +
  +            "  two: 22.2,\n" +
  +            "  three: many words\n" +
  +            "}\n" +
  +            "---\n";
  +    Wire wire = new TextWire(Bytes.from(text));
  +    MethodReader reader = wire.methodReader(writer2);
  +    assertTrue(reader.readOne());
  +    assertTrue(reader.readOne());
  +    assertFalse(reader.readOne());
  +    assertEquals(text, wire2.toString());
  +}
  +----
  +
  +
  +== Uses of Chronical Wire
  +
  +Chronical Wire can be used for:
  +
  +* file headers
  +* TCP connection headers; where the optimal wire format taht is actually used can be negotiated
  +* message/excerpt contents
  +* Chronicle Queue version 4.x and later
   * the API for marshalling generated data types.
   
   == Similar projects
   
   === SBE
   
  -Simple Binary Encoding is designed to do what it says.
  -    It's simple, it's binary and it supports C++ and Java.  It is 
  -    designed to be a more efficient replacement for FIX. It is not limited to FIX 
  -    protocols and can be easily extended by updating an XML schema.
  -    
  -XML, when it first started, didn't use XML for it's own schema files, and it's not
  -   insignificant that SBE doesn't use SBE for it's schema either.  This is because it is
  -   not trying to be human readable. It has XML which, though standard, isn't designed
  -   to be particularly human readable either.  Peter Lawrey thinks it's a limitation that it doesn't
  -   naturally lend itself to a human readable form.
  +Simple Binary Encoding (SBE) is designed to be a more efficient replacement for FIX. It is not limited to FIX protocols, and can be easily extended by updating an XML schema. It is simple, binary, and it supports C++ and Java.
  +
  +XML, when it first started, didn't use XML for its own schema files, and its not
  +   insignificant that SBE doesn't use SBE for its schema either.  This is because it is not trying to be human readable. It has XML which, though standard, isn't designed to be human readable either.  Peter Lawrey thinks that it is a limitation that it doesn't naturally lend itself to a human readable form.
      
  -The encoding SBE uses is similar to binary, with field numbers and fixed width types.  
  -   SBE assumes the field types, which can be more compact than Wire's most similar option 
  -   (though not as compact as others).
  +The encoding that SBE uses is similar to binary; with field numbers and fixed width types.
  +
  +SBE assumes the field types, which can be more compact than Wire's most similar option; though not as compact as others.
      
  -SBE has support for schema changes provided the type of a field doesn't change.
  +SBE has support for schema changes provided that the type of a field doesn't change.
      
  -=== msgpack
  -
  -Message Pack is a packed binary wire format which also supports JSON for 
  -    human readability and compatibility. It has many similarities to the binary 
  -    (and JSON) formats of this library.  c.f. Wire is designed to be human readable first, 
  -    based on YAML, and has a range of options to make it more efficient.
  -    The most extreme being fixed position binary.
  -    
  - Msgpack has support for embedded binary, whereas Wire has support for
  -    comments and hints to improve rendering for human consumption.
  +=== Message Pack (`msgpack`)
  +
  +Message Pack is a packed binary wire format which also supports JSON for human readability and compatibility. It has many similarities to the binary (and JSON) formats of this library.  Chronicle Wire is designed to be human readable first, based on YAML, and has a range of options to make it more efficient. The most extreme being fixed position binary.
  +    
  +Message Pack has support for embedded binary, whereas Chronicle Wire has support for comments and hints, to improve rendering for human consumption.
       
   The documentation looks well thought out, and it is worth emulating.
   
  
positive.code: 
  == Binding to a field value
  
  While serialized data can be updated by replacing a whole record, this might not be the most efficient option, nor thread safe. Wire offers the ability to bind a reference to a fixed value of a field and perform atomic operations on that field such as volatile read/write and compare-and-swap.
  
  [souurce, Java]
  ----
     // field to cache the location and object used to reference a field.
     private LongValueReference counter = null;
  
negative.code: 
  Wire optionally supports:
  
  - field name changes
  - field order changes
  - capturing or ignoring unexpected fields
  - setting of fields to the default, if not available
  - raw messages can be longer or shorter than expected
  
  The more flexibility, the larger the overhead in terms of CPU and memory.  
  Wire allows you to dynamically pick the optimal configuration, and convert between these options.
  
  === Zero copy.
  
  Chronicle Wire supports zero-copy random access to fields, and direct-copy from in-memory to the network.
  It also supports translation from one wire format to another. For example, switching between fixed-length data and variable-length data.
  
  === Random Access.
  
  You can access a random field in memory, For example, in a 2TB file, page in/pull into CPU cache, only the data relating to your read or write.
  
  [options="header"]
  |===============
  | format | access style 
  | fixed-length binary | random access without parsing first
  | variable-length binary | random access with partial parsing. i.e. you can skip large portions
  | fixed-length text | random access with parsing
  | variable-length text | no random access
  |===============
  
  Chronicle Wire references are relative to the start of the data contained, to allow loading in an arbitrary point in memory.
  
  === Safe against malicious input.
  
  Chronicle Wire has built in tiers of bounds checks to prevent accidental read/writing that corrupts the data. It is not complete enough for a security review.
     
  === Reflection / generic algorithms.
  
  Chronicle Wire supports generic reading and writing of an arbitrary stream. This can be used in combination with predetermined fields.
  For example, you can read the fields you know about, and ask it to provide the fields that you don't.
  You can also give generic field names like keys to a map as YAML does.
  
  === Initialization order.
  
  Chronicle Wire can handle unknown information like lengths, by using padding.
  It will go back and fill in any data that it wasn't aware of when it was writing the data. For example, when it writes an object, it doesn't know how long it is going to be, so it adds padding at the start. Once the object has been written, it goes back and overwrites the length. It can also handle situations where the length was more than needed; this is known as packing.
  
  === Unknown field retention?
  
  Chronicle Wire can read data that it didn't expect, interspersed with data it did expect. Rather than specify the expected field name, a `StringBuilder` is provided.
  
  Note: There are times when you want to skip/copy an entire field or message, without reading any more of it.  This is also supported.
  
  === Object-maximumLimit RPC system.
  
  Chronicle Wire supports references based on name, number, or UUID. This is useful when including a reference to an object taht the reader should look up by other means.
     
  A common case is if you have a proxy to a remote object, and you want to pass or return this in an RPC call.
  
  === Schema language
  
  Chronicle Wire's schema is not externalised from the code. However it is planned to use YAML in a format that it can parse.
  
  === Usable as mutable state
  
  Chronicle Wire supports storing an application's internal state. This will not allow it to grow or shrink. You can't free any of it without copying the pieces that you need, and discarding the original copy.
      
  === Padding takes space on the wire.
  
  The Chronicle Wire format that is chosen determines if there is any padding on the wire. If you copy the in-memory data directly, its format doesn't change.
  
  If you want to drop padding, you can copy the message to a wire format without padding. You can decide whether the original padding is to be preserved or not, if turned back into a format with padding.
  
  We could look at supporting *Cap'n'Proto*'s zero-byte removal compression.
  
  === Un-set fields take space on the wire?
  
  Chronicle Wire supports fields with, and without, optional fields and automatic means of removing them. Chronicle Wire doesn't support automatically adding them back in, because information has been lost.
  
  === Pointers take space on the wire.
  
  Chronicle Wire doesn't have pointers, but it does have content-lengths, which are a useful hint for random access and robustness; but these are optional.
  
  ===  Platform support
  
  Chronicle Wire supports `Java 8`.  Future versions may support `Java 6`, `C++` and `C#`.
  
  