My reading of this is that the Chrome Web Store is where apps are listed and users authorize them, but not necessarily that the app has to run in a web browser. The user could authorize the app by "installing" it through the Chrome Web Store but download/use it from a totally different channel.
PS: I work at Google but don't have any inside info on this.
I understand that. There's no way to have the web store install a native app.
But once you have "installed" the web app, how would the API server have any idea whether a Google Drive API request was coming from a web server, some JavaScript running in a web browser, an Android app, or a remote island in the Pacific that has no electricity via the "IP over Avian Carriers" protocol? It's just HTTP requests with some authorization headers that tie it to your app's identity.
Google Drive synchs to your local hard drive, and thus works with all of your apps. (Right?)
It ALSO has a Chrome interface to be clever. Picture opening a 1,000 page PDF. If the Chrome PDF Viewer knows how to fetch individual pages on demand, do searches on the server side, etc., it could be very nice for quick previews, etc.
Also, it works great for one content creator (who has the app on the desktop), and a bunch of content viewers (and commenters) who just need Chrome.
I think its a pretty stupid move. If they really want developers to flock to Google drive, they should not limit the api to their little corner of the world. I'm guessing that they are going to open it to all apps eventually.
It seems you don't understand what CAPTCHAs are for on a large site. The purpose of a CAPTCHA is to make it expensive for automated systems to make fake accounts on your site. If the CAPTCHA requires them to hire people via Mechanical Turk to solve it then it has done it's job. If it requires a one line JQuery statement then it is a complete #fail.
Thanks. Sorry to read about your trouble. Now that I know what's going on, I can live with the redirect if it's more expedient/effective to leave it in place particularly over the short term.
That solution doesn't address my question. Caching @reply subscribers only addresses the 3% of users who have opted-in to receiving all @replies. For the remaining 97% whether they receive @replies from someone they are following or not is a function of which user the reply is directed to and whether that user is also their friend. You can't cache that, at best you can optimize how you calculate who should receive replies.
In fact, what you've pointed out is that building an implementation to address the 3% case is straightforward which was the point of my post.
PS: My blog does have a commenting feature. In fact there are 3 comments in response to the post.
If you're interested in wild speculation (I have no idea how Twitter's database works), here's how I interpreted Biz's explanation:
With the new system, say user Foo writes "@Bar lol me too!". Then Twitter can take Foo's follower list, join it with Bar's follower list, and send the message to everyone in the resulting list. Relational databases are very good at joins.
On the other hand, with the old system, they'd have to do a deep inspection of the record for each of Foo's followers to know if they should send the message to that follower. Relational databases are much less good at this.
But, as you and others have pointed out, if the number of users that use the "all @-replies" feature is really so small, it would be fairly inexpensive to cache the list of all of Foo's followers who use that feature, and join them in as well. I don't know why they don't do that -- maybe it adds up (like, if only 3% of users use the feature, but those users follow a lot of other users, they'll each end up in a lot of other users' caches).
The 3% (of users affected) number has been trotted out a few times. Has twitter ever backed that up? It feels like a way of marginalizing the people who're complaining about the change, by painting them (us) as a vocal minority.
Taking into consideration the fact that the percentage of people likely to put in the time to explore documentation and settings and discover the original configurability is probably quite small, and a reasonable assumption that not everyone who discovers the functionality will use it, yeah, the number sounds all right.
Note, btw, that the number they seem to be going for is the above -- e.g., "according to the accounts database, only 3% of users ever changed this setting", _not_ "only 3% of users are claiming to care about this now that it's been removed".
PS: Yes, I work on the SkyDrive developer platform. It doesn't change the truth.