u1db-discuss team mailing list archive

[Stuart Langridge <stuart.langridge@xxxxxxxxxxxxx>]

On Wed, 2011-11-16 at 09:48 -0500, Rodney Dawes wrote:
> >  We're
> > talking about JSON because that's the format your implementation has to
> > talk in order to do syncs.
> 
> This is mostly irrelevant. If it *HAS* to be JSON in the sync protocol,
> then the obvious best solution for client/server is to just store that
> blob of JSON in whatever container it prefers to use.

Not at all. An implementation does three things: it converts stored
documents to JSON for sync, it converts stored documents to $something
for API calls, and it maintains and searches against indexes. The whole
reason that we don't say "you have to store stuff in JSON" is because
you might be able to find a better way to store it that makes indexes
better. One of the things we don't actually *know* yet is where the good
tradeoff lies between "doing stuff for sync" and "doing stuff for index
queries": my personal belief is that the data will get hit a lot more
for indexes than it will for sync/store, meaning that implementors
should bias how they store things toward making indexing easier and
sync/whole-doc-retrieval harder. But that's a belief with basically no
evidence at this stage; we just don't know, yet.

sil