Yes. :P I think rather than a list, we have a journey.
It starts here: it's tempting to use Couch -- hey, it looks like it buys us a lot for free. Replication, object storage, client libraries, looks like a fit for a record-oriented data model. Records are a bit like documents, after all. OK, but we won't want to expose our Couch cluster to the world. For one thing, we might need to switch backends for operational reasons. And we almost certainly need to put some logic in a server -- validation, auth, buffering, consistency, monitoring, attack mitigation, security auditing. So we build a server in front of it. But maybe for now we can start with plain Couch. Also, we can't use off-the-shelf replication (either client-server or server-server), because we can't control local space usage, OK, so we build our own Couch Protocol client, right? That'll let us control how we move data around. But we can't just use the Couch Protocol. It doesn't give us the guarantees we want to achieve performance, consistency, and safe structural manipulation -- ordering of records, collection deltas -- and we'd also need to extend it for auth, for not-yet-fleshed-out app-specific semantics, for collections. A few steps down this road and we've got Couch… only not a Couch server, speaking not the Couch protocol, and not using Couch clients. So we come down to two or three things, all of which I think are sane: * Using Couch as server-side storage. I leave this up to Ryan's excellent judgment. * Taking some inspiration from the Couch protocol (even to the extent of being able to build a client-side adapter to talk directly to Couch; basically implementing the server layer/custom protocol directly in the client). * Maybe, for the set of totally independent datatypes (which is very small) for which we're OK having a full local replicated copy and server-side conflict management, using Couch as another data storage backend. If I were writing Deb's task list app, I'd be really tempted to just say "screw it, let's dump it into Couch and let the protocol sort it out", if that buys us anything. I'm fairly confident that we can end up with a pretty slim server (which'll make Ryan happy), and a blob exchange protocol that isn't light years away from Couch's (which'll make Chris happy), on which we can build a consistent, robust, and performant syncing architecture (which'll make me happy). Does that answer your question? -R On 24 Jul 2013, at 10:08 PM, Lloyd Hilaiel <[email protected]> wrote: > I imagine tomorrow at the design review we'll want to spend some time talking > about CouchDB. > > If you had to summarize all the unknowns, or areas of concern, would they > fall into this list? > > # Structured data (bookmarks!) > # Protocol Limitations > # Client resource usage > # Data Representation > # Scalability > > ? > > lloyd > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
