new encoding schemes for backends that support JS types

[timkuijsten]

For backends like IndexedDB that support native JS types, should we introduce something like none, js or native as a valid encoding for keyEncoding and valueEncoding?

related to #83

[juliangruber]

you can already write a custom encoding, a la

var noop = function(){};
var none = { encode: noop, decode: noop };
db({ valueEncoding: none, keyEncoding: none });

iirc that should work, but haven't tried it

[vweevers]

This is supported, but note there's two layers to this.

1. Encoding. The user of level(up) must use the none aka id encoding. E.g. valueEncoding: 'id'.
2. Serialization. The backend must implement _serialize* as identity functions:

down.prototype._serializeKey = function (key){ return key }
down.prototype._serializeValue = function (value){ return value }

It's very likely we'll make this the default behavior. So in the future, only the backends that need to (because they can only store a subset of types - e.g. buffers and strings in leveldown) will have to implement _serialize*.