BTW, one can programmatically take a screen shot on OS X with /usr/sbin/screencapture (where the -x flag means screencapture should not play the usual "camera click" sound).
Details are in this article: http://messymatters.com/tagtime
Short version: TagTime randomly samples you with a popup, asking what you're doing right at that moment. You never have to remember to do anything, so it's essentially passive. But you're not trusting the computer to infer what you're doing, so it's perfectly accurate (asymptotically -- you need a week or so of data for the inherent noisiness to average out, ie, to get a big enough sample size).
Part of my suggestion, left unspoken above, is that once a day or once a week, the person would "review" the screen shots. During this review, the same (time-stamp, tag) pairs would be (manually) created that are created by your pop-ups. Its just that the "pairs" (or records) would be created in batches, rather than at the time of the events they refer to.
Now that I am done trying to head off a possible misconception, let me say that I plan to try your way, because there is already software available to support it. (I have software to automatically create the screen shots, but not software to support the task of reviewing the screen shots while manually creating the (time-stamp, tag) pairs.)
But for people who don't like getting interrupted by the popups, your solution sounds good. (I find the popups aren't distracting at all -- they even tend to reinforce what I'm focusing on, or remind me to refocus if I was distracted. It's not like getting interrupted by email where it pulls your attention away from what you were trying to focus on.)
Seems useful. I made 2 comments over at http://beeminder.uservoice.com/forums/3011-general/filters/n....
So we added the "username" endpoint, but weren't (and still aren't) quite satisfied with that as a solution. Have other API designers run into this same issue? Seems pretty common - would like to hear what HN has to say about it.
1. Make the OAuth server end append additional parameters to the successful-auth URL. It would end up looking like http:// some-app.com/oauth-ok?access_token=abc123&username=jdoe
2. Provide an endpoint with the same data as /user/<name>.json, but without the uesrname in the URL. OAuth clients would query this new endpoint instead. While you're at it, might as well allow the client to request the goal list at the same time. Ideally, a client should only have to send a single request to populate its "home page".
We're taking both your suggestions: username is returned along with
the token as part of the oauthing, and also you can just use "me" in
place of the username for any endpoint, and it's essentially
No more lame-o dummy resource just for getting the username! (Well
we're leaving it there in case anyone has already written code that
uses it but it can now be undocumented.)
Thanks again for the help!