Raindrop/SoftwareArchitecture/Hosting

couchdb hosting

A couple of companies provide couchdb hosting services (http://hosting.couch.io/ and http://cloudant.com/) We should touch-base with them and see if they are willing to provide the couchdb hosting for raindrop (possibly for free, in exchange for co-branding the raindrop installs hosted there). The hosting provider would be responsible for backing up the couchdb databases, as well as general locking down of the couchdb servers from outside attach.

This should be addressed ASAP, as it may impact all other issues. It was felt that David would be the best to make an initial approach.

authentication and authorization

Raindrop currently doesn't need document-level authorization; a user either has no access to a database, or full access. The concept of 'read-only' access is unlikely to be needed - someone with read-only access can see very personal information. It is possible something like "write only access, and only to certain documents" would be desirable so raindrop can be upgraded - see below - but we are likely to punt on that for now.

We will use some 'middle-ware' in between the user's browser and couchdb itself. This middleware will provide SSL access plus authentication and authorization. The couchdb hosting provider's requirements are likely to impact us here, so specific products haven't been discussed - although something like "ssl cookies" (what are they? markh) should work.

Support/Debugging/Metrics

Providing support and debugging problems will be difficult as the raindrop devs should not have access to the individual databases. Diagnosing problems will not be as easy as looking in the database. Even making the logfiles public may be problematic - even though passwords are not written to the logs, other potentially sensitive information may be.

Similarly, we will want a metrics system in place so we can see how people are using raindrop without reading the main database.

Upgrading raindrop - rolling out new versions

In a perfect world, no MoMo staff/support people will have access to the databases - but at the same time, we need some way of installing new versions of raindrop into an existing database. We may be able to come up with a process which allows us to publish the new version to a public DB, then have each user "pull replicate" from that DB to get the new version.

Upgrading raindrop - new database formats

Some changes to raindrop require changes to existing documents before it can work. In extreme cases we may ask that the database be deleted and rebuilt from scratch. This is unlikely to be tenable in a hosted environment.

One solution may be that we consider some schemas to be "important" (eg, the raw emails), so insist they either never require being deleted - at worst, an upgrade process would be necessary to convert existing documents to a new format. We could then consider all documents "derived" from those document (eg, documents created by individual extensions) as able to be deleted and re-create by re-running the new extension.

Solutions

Documents could store the 'version' of the extension used to write the document. When an incompatible change is made to an extension, the version number could be bumped which could trigger the extension to be re-run over all documents with an earlier version.

It may also be necessary to include a "schema version" (as theoretically, the version of a schema is independent of the version of whatever extensions create the schema). In practice though, if a schema definition changes, all extensions which write the schema will also need to change, so the extension version may be acceptable)