Currently, the transport layer is specific to the CouchDB API. For example, the RequestOptions struct contains values for CouchDB-specific query parameters. Consequently, to add support for a new query parameter, the programmer must extend RequestOptions by adding a new field, as well as touching several other points in the transport layer to handle that new field.

Currently, executing an action requires unwrapping of two results:

let foo = db.action().unwrap().run().unwrap();

For some actions, there are a few more, like when you're receiving a document:

let content = foo.get_conent().unwrap();

This results in a lot of nested try! calls. IMO, we should change the actions to return Self and store the path as Result<Path, Error> that gets unwrapped in run(). That's also how hyper does it.

The ExecuteView action, along with related types such as ViewResponse, require applications to explicitly provide Key and Value type parameters. Consider changing the API to allow for type inference.

The path-related types should be as convenient to use as possible while retaining strong type-safety to guard against, say, a programmer mistakenly referencing a normal document when a design document is needed. See my commentary below for what this means specifically.

~~As they're currently implemented, the path-related types cannot all implement Borrow. E.g., impl std::borrow::Borrow<DocumentPathRef> for DocumentPath makes no sense. One consequence is that when these types are stored as keys in a HashMap, each lookup into that collection requires a temporary heap allocation.~~

~~Here's the relevant StackOverflow question: http://stackoverflow.com/q/36480845/1094609~~

~~By using a Cow as the underlying storage for path-related types, we could implement Borrow. We could also eliminate the distinction between owning-types and borrowing-types—e.g., DocumentPath and DocumentPathRef<'a> would collapse into a single DocumentPath<'a> type. However, one downside is that the new type would require a lifetime parameter, which may be too bitter a pill to swallow.~~

Add support for the include_docs query parameter when executing a view. Doing so will require changing the ViewRow type to optionally contain a Document.

~~It might be a good idea—either now or later—to make a new reference-counted document path type, similar to DocumentPath, whereby the database name component is stored as a std::rc::Rc<DatabaseName>. Otherwise, each view row containing a document will have a copy of the same database name, which could lead to a lot of allocations. I envision the reference-counted document path type to be an private type inside Chill.~~

The reference-counting idea is probably a bad idea. The std::rc::Rc type implements !Send, meaning Rc prevents anything containing it from moving to another thread. Having a Document (or ViewRow) contain an Rc would be prioritizing for efficiency over convenience—contrary to the central aim for Chill. For this specific case, it would be better merely to incur the cost of one extra allocation per document for the database name, as that cost will be lost in the noise of doing an HTTP round-trip with the CouchDB server.

Define a set of types that applications may use to represent design documents or parts of design documents. E.g.,

pub struct Design {
    pub views: HashMap<String, ViewFunction>,
    // ...
}

Here are the issues for adding support for group-reduced views: #23 and #24.

~~Group-reduced views are technically reduced, but, structurally, their responses have the same form as unreduced views in that they consist of an array of key–value pairs.~~ Correction: Group-reduced view responses lack the total_rows and offset fields.

~~Instead of distinguishing the two view variants by reduced vs unreduced, we should distinguish by scalar (i.e., value only) vs non-scalar (i.e., array of key–value pairs).~~

Group-reduced view responses may have multiple rows, with each row containing a non-null key and a value. Currently, Chill's ViewResponse enum has two variants, Reduced and Unreduced, with the reduced variant having exactly one value.

It may make sense to convert ViewResponse from an enum to a struct, thereby eliminating the distinction between reduced and unreduced views.

Currently, all Client methods that construct an action do so fallibly, returning a Result. For ergonomics, consider pushing fallibility to the time that the action executes so that the Client method always succeeds and returns the action type.

ViewRow contains an Rc<DatabaseName> as an optimization. However, this has the effect of making the ViewRow implement !Send. See #19 for more commentary.

I.e., the follow snippet causes a compile-time error:

fn f<T: Send>(_: T) {}
f(ViewResponse::Reduced(ReducedView {
    update_seq: None,
    value: 42,
}));

Add support for optionally including attachment content as part of reading a document. This can at first be implemented by using the ?attachments query parameter for GET /db/doc, though long-term this should be implemented using multipart.

A lot of the infrastructure for handling document attachments is already implemented as of v0.1.0, but some design work will need to be done to expose the attachments via the Chill API.

The Document type relies on an AttachmentName type aliased to a String. Replace this with a real AttachmentName type (analogous to the DatabaseName type). Here's a snapshot of the source.

It makes the most sense to resolve this when Chill's API gains support for attachments.

Currently, applications specify start and end keys for views only by value.

Chill should also support specifying keys by reference so as to eliminate a key copy in some cases.

Currently, the ExecuteAction has two methods for setting the “end key”:

• with_end_key_inclusive
• with_end_key_exclusive

Consider generalizing both methods into one method—something like:

fn with_end_key<K>(self, end_key: K, inclusivity: ???) -> Self

The ??? may be a marker type, with one type denoting inclusivity and another denoting exclusivity.

~~Note another change: the key parameter is a reference, not a value.~~

After successfully running the UpdateDocument action, Chill should change any unsaved attachments in the document to the Saved variant. Otherwise, Chill may redundantly upload the attachment if the document is updated again.

This action would not model an HTTP action in the CouchDB API. Instead, it would comprise two CouchDB actions: (1) reading a document, followed by (2) overwriting the document if and only if the document's content (read in step 1) is different than the new content provided by the application.

The intended purpose of this new action is to make it easier for applications to keep design documents up-to-date. Applications would, upon startup, run this action once for each design document, with the result that only out-of-date design documents would be overwritten.

Beyond the scope of this issue, it may make sense to provide another action, one that forcibly overwrites multiple documents. This new action would read via an HTTP POST request to the _all_docs resource (to read multiple specific documents by id), followed by updating some of the documents via an HTTP POST request to _bulk_docs.

Currently (as of v0.2.0), when an action fails, the resulting error message does not include the action name. Consequently, if the application runs many actions and one fails, then it's not immediately clear which action failed.

Currently, ViewRow clones and re-decodes (from JSON) the row's key and value in its key and value methods. It map be better to avoid this duplication of effort. Perhaps we could store the raw JSON text and do the decoding only once, during the call to key or value.