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

[Richard Weait]

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.

OSM must support mappers first. And mappers love to see their edits
appear on tiles.  Therefore we must provide tiles to mappers.  Any
application or use that interferes with resources for mappers must be
routed around.  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.

This is not to say that the api / tile limits can't be discoverable.
Just that any fixed guidelines for non-editor use will hurt OSM
long-term.