From 9629330a840d46d378ae3c13f67ea066b539cc9a Mon Sep 17 00:00:00 2001
From: Nicholas Fraser <nicholas.rd.fraser@gmail.com>
Date: Mon, 2 Mar 2015 08:44:23 -0500
Subject: [PATCH] Added documentation link, removed expect API primer (to be
 moved to separate documentation page)

---
 README.md | 61 +------------------------------------------------------
 1 file changed, 1 insertion(+), 60 deletions(-)

diff --git a/README.md b/README.md
index 1fff533..8e9029b 100644
--- a/README.md
+++ b/README.md
@@ -7,7 +7,7 @@ MPack is a C implementation of an encoder and decoder for the [MessagePack](http
  * Secure against untrusted data
  * Lightweight, suitable for embedded
  * Helpful for debugging
- * Extensively documented
+ * [Extensively documented](http://ludocode.github.io/mpack/)
 
 The core of MPack contains a buffered reader and writer with a custom callback to fill or flush the buffer. Helper functions can be enabled to read values of expected type, to work with files, to allocate strings automatically, to check UTF-8 encoding, and more. The MPack featureset can be configured at compile-time to set which features, components and debug checks are compiled, and what dependencies are available.
 
@@ -68,65 +68,6 @@ If any error occurs, the writer is placed in an error state and can optionally l
 
 The MPack writer API is imperative in nature. Since it's easy to incorrectly compose structured data with an imperative API, MPack provides a debug mode which tracks reads and writes of compound types to ensure that the correct number of elements and bytes were read and written. This allows for rapid development of high-performance applications that use MessagePack. In release mode, these checks are eliminated for maximum performance.
 
-## The Expect API
-
-The Expect API is used to imperatively parse data of a fixed (hardcoded) schema. It is useful when parsing very large mpack files or parsing in memory-constrained environments. The below example demonstrates shows reading from a file and handling errors with longjmp.
-
-    // open a file on disk
-    FILE* file = fopen("example.mp");
-    if (file == NULL) {
-        fprintf(stderr, "An error occurred opening the file!\n");
-        return;
-    }
-
-    // initialize the reader using fread() and a stack-allocated buffer
-    mpack_reader_t reader;
-    mpack_reader_init_stack(&reader, mpack_fread, file);
-
-    // catch errors with longjmp
-    if (MPACK_READER_SETJMP(&reader)) {
-        fprintf(stderr, "An error occurred decoding the file!\n");
-        mpack_reader_destroy(&reader);
-        fclose(file);
-        return;
-    }
-
-    // we expect the file to contain the example on the msgpack homepage
-    mpack_expect_map_match(&reader, 2);
-    mpack_expect_cstr_match(&reader, "compact");
-    bool compact = mpack_expect_bool(&reader);
-    mpack_expect_cstr_match(&reader, "schema");
-    int schema = mpack_expect_int(&reader);
-    mpack_done_map(&reader);
-
-    // clean up
-    mpack_reader_destroy(&reader);
-    fclose(file);
-
-    // verify and use the data
-    if (!compact || schema != 0) {
-        fprintf(stderr, "The file data is invalid!\n");
-        return;
-    }
-
-The example expects the map elements to be laid out in a specific order. If you expect map keys to be re-arranged (for example if the data is converted from JSON or encoded from an unordered map), something like this may be more appropriate:
-
-    bool compact = false;
-    int schema = -1;
-
-    for (int i = mpack_expect_map(&reader); i > 0; --i) {
-        char key[20];
-        mpack_expect_cstr(&reader, key, sizeof(key));
-
-        if (strcmp(key, "compact") == 0)
-            compact = mpack_expect_bool(&reader);
-        else if (strcmp(key, "schema") == 0)
-            schema = mpack_expect_int(&reader);
-        else
-            mpack_reader_flag_error(&reader, mpack_error_data);
-    }
-    mpack_done_map(&reader);
-
 ## Why Not Just Use JSON?
 
 Conceptually, MessagePack stores data similarly to JSON: they are both composed of simple values such as numbers and strings, stored hierarchically in maps and arrays. So why not just use JSON instead? The main reason is that JSON is designed to be human-readable, so it is not as efficient as a binary serialization format: