Raindrop/Weekly Call/2009-10-27

Participants

Andy, Bryan, James, Mark

Status

• Andy and Bryan working on Design Iteration #3, which merges original inflow with Grid. They posted mocks to Flickr and design blog. They continue to refine iteration #3.
• James pushed changes to the inflow to conform to Iteration #3, and removed the old inflow and inflowgrid. All CSS is now in the inflow folder. He will continue to work on that cleanup and streamlining the JS API layers so they can be ported to a server based API.
• Mark investigated couchjs for use for our APIs, but the curl support is broken. So we need to wait for couchdb changes to get fixes for it, which means upgrading the couch. He will now switch to a python-backed server API layer for now that loads the API code from the couch, so we can start playing.

Bigger Issues

Things that require more discussion:

Repo management

Mark brought up on raindrop-dev how we should do development. It seems like using clones to collaborate with others, that use our personal web spaces on the moz servers is a way to start, but please comment if you have used hg a lot.

We still need to decide how stable we want to keep trunk. Mark talked about keeping trunk relatively stable and perhaps a clone for dev work, like the work to use couch trunk to get a viable server JS environment, then only push to trunk when things are relatively stable.

We need more input on this, so see Mark's email thread on raindrop-dev.

How to get metrics

We are not sure how best to get metrics from people's raindrops yet. We originally talked about just having some HTTP server that gets hit with metrics urls and we would just comb through the HTTP logs, but we are wondering if we can leverage something else:

Bryan is going to talk to someone who has used Test Pilot to see how the metrics are collected there.

Mark will look at postbox to see how they collect metrics. Apparently they use some sort of open source thing.

James wants to collect the metrics in a user's CouchDB in a DB alongside Raindrop, then replicate those metrics to a CouchDB on one or our servers. It is not clear if this is scalable or worth the trouble. But Mark mentioned that he thought there was a way for Couch's Futon to send local test results back to a common server.

Bryan talked about wanting to first collect the unique number of domains that the user receives mail from, so that can inform how we design the notifications in Iteration #3.

Ideas here are appreciated.

Maple Milestone Planning

The team is currently working on the tasks listed on the Maple milestone page. We will be opening up specific trac tickets to track progress.