> Does that answer your question? Kinda. Let me try to map this onto a small summarized set.
On Jul 24, 2013, at 11:25 PM, Richard Newman <[email protected]> wrote: > 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. Monitoring, attack mitigation, and security auditing don't seem unique to couchdb. Buffering and consistency perhaps fall under "Protocol Limitations" > 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. Which sounds like "Client resource usage". > 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. "Protocol Limitations" and perhaps "Scalability" and maybe "Data Representation" (thinking that protocol limitations can pretty deeply affects representation design, not everyone agrees). > 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). Ok, I'm admitting we're going to have a pretty protracted conversation on this tomorrow, and just wanted to ensure concerns were represented. I *think* I've done a fair job. We shall see! :} lloyd > -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
