initial public api spec

[jchris]

This is the test we expect all versions of 1.x to pass. If we break this test, we are talking about 2.0

Let's review and discuss before we merge. These are the main feature areas to specify:

• Query options and response object shape for db.query(), db.allDocs(), db.changes() and db.subscribe() can be normalized.
• Metadata like doc._id are implicitly specified here, we can do better
• We should specify _proof or something similar to give access to the underlying Merkle integrity
• The history API will come post 1.0 but this is a good context to think about it.

Adding assertions (not removing them) from this test is how we know we are getting close to a new 1.1, 1.2, etc

[jchris]

Also relevant are questions about renaming "database" to "document" in which case what do we call the return of const val = document.get('id')?

Candidate names are val (value) rec (record) it (item), any others?

[mabels]

async () =>

[mabels]

function =>

[mabels]

why not fireproof?

[mabels]

Nice

[mabels]

i would go for this:

const tdb = db.typed<DocType>() // this will not break with the old api
interface TypedItem<T> {
    meta: Meta
    data: T
}
interface TypedDatabase<T> {
    get(key): Result<TypedItem>
    put(typedItem: T| TypedItem<T>): Result<TypedItem<T>>
    query(key: T|AllDocs): Result<TypedItem<T>[]> // we don't need AllDocs
    subscribe(key: T|AllDocs, CB: (TypedItem<T>[]) => Result<void>): Result<Registration>
    // do we need changes?
}

[jchris]

I like the suggestion of collection or ledger for what we call "database" now

[mabels]

Please add the iterator and readstream api to alldocs/query.
If you need help --- ask