Raindrop/SoftwareArchitecture/Hosting
Contents
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.
Action Items
Someone (who?) to contact the couch hosting providers to see if they can help.
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 middleware 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 and secure session cookies should work.
Action Item
Gozer to propose something here.
encryption of highly-sensitive information
We currently need the password to IMAP and to Twitter. If we support only gmail, we then are storing their google account password. Leaking this could have bigger consequences than simply leaking the emails. Currently we store the passwords, in clear text, in the user's HOME directory and rely on the operating system to secure that folder. Depending on the hosting strategy, this may or may not be possible.
Action Item
???
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.
Action Item
Bryan: more ideas for what to collect. ?????: implement stats collection into new local DB ?????: replicate or otherwise publish local DB to public area.
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. Note however, we do not want this to be an explicit action by the user; if implemented, it must be implicit.
Action Item
?????
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)
Action Item
Mark to implement extension versioning?
