[OSM-talk] Exceeded API bandwidth limit, now what?
mike at stamen.com
Tue Sep 14 20:31:24 BST 2010
On Sep 14, 2010, at 12:20 PM, Richard Weait wrote:
> On Tue, Sep 14, 2010 at 3:07 PM, Michal Migurski <mike at stamen.com> wrote:
>> It'd be interesting if the limit was in some way discoverable. I understand that it's not a game, but it would be immensely helpful if the back-off message was advisory rather than punitive. I can imagine this being expressed as HTTP headers that let you know how long to wait until your next request, or how close a client is to being blocked. I can adapt to whatever the current limitations are, but only if they're communicated in a machine-parseable way.
> The risk with setting quantified guidelines is that somebody will
> interpret that limit as either a promise of performance or a maximum
> acceptable use of resources. Then a few hundred more iWhatever
> applications will make the same "reasonable" demands on OSM resources
> and be upset that we're hurting their business model when we move the
> guidelines down, or cut them off without notice.
I definitely agree with this, which is why I think it'd be good for it to be a mutating, advisory limit based on circumstances. I'm not sure what precedents exist for this, but if the API responded with headers that informed the client of time-until-cutoff, then it would be possible to dynamically rate-limit in favor of mappers and editors.
> Yes, providing tiles for the curious newcomer, casual
> user, and busy entrepreneur is useful promotion of OSM. But it can
> not be at the expense of mappers. Blocks, to date, have only been
> applied to users who lie vastly outside of the average user. The very
> smallest fraction of one percent of all users, consuming an enormous
> relative percentage of the resources.
Fully agreed as well. It'd just be nice if the limitation weren't expressed as a hard "fuck off" but a soft "slow down".
michal migurski- mike at stamen.com
More information about the talk