Re: [w3c/IndexedDB] JSON schema specification (#64)

Since the JSON Schema project was not interested in incorporating IndexedDB elements, here's an alternative approach which covers the OP use case along with providing an even greater justification for defining such a format...

1. First define a standard JSON-based serialization of structured clones along with an HTTP content type and headers to go with it (to indicate key at least if out-of-line or keyPath if inline)? This would be useful in-and-of itself as cloned data could be reconstructed as easily as, e.g., getting a full structured clone as opposed to JSON via XHR from a server. Other methods like PUT could be employed to allow RESTful updates to individual stores. The various HTTP Patch protocols (e.g., [JSON Patch](https://tools.ietf.org/html/rfc6902) or [JSON Merge Patch](https://tools.ietf.org/html/rfc7396)) could be leveraged to allow a well-known means of partially updating an IndexedDB store on a server (or even a client, I suppose if headers could go along with local URLs as per #57).

As far as a possible implementation format, FWIW, in [IndexedDBShim](https://github.com/axemclion/IndexedDBShim), we are representing cyclic objects and cloneable built-in objects part of the SCA via the [typeson](https://github.com/dfahlander/typeson) format (specifically utilizing the structured clone representation in the [typeson-registry](https://github.com/dfahlander/typeson-registry)).
2. Create another JSON format which builds on top of the individual store format to include all JSON-serialized store content (say within an array) as well as the necessary meta-information to reconstruct a full database (keyPath, indexes, version number, etc.).

Normal REST principles could then be applied at either level. Perhaps some HTTP method could allow retrieval of a count of the stores or such.

3. Finally, upgrade paths for client-side as well as server-side use, across multiple versions could be specified by JSON Patch (or if people were inclined to start over to get a more compact but equally expressive format, I've given a sample of my own [here](https://github.com/json-schema-org/json-schema-spec/issues/15#issuecomment-211248417)). (JSON Merge Patch is nicely succinct and intuitive but not expressive enough to cover all cases.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/64#issuecomment-298591208