[OSM-talk] Exceeded API bandwidth limit, now what?

[Michal Migurski]

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".

-mike.

----------------------------------------------------------------
michal migurski- mike at stamen.com
                 415.558.1610