Right now the token_dispenser waits as necessary, enforcing the rate limit by pausing. But it's conceivable that a programmer might also want the option of dropping calls to enforce the rate limit, never pausing. As an example, these guidelines for the Mapzen autocomplete function, which link to an interactive demo comparing javascript's throttle() and debounce().
To implement this, the token_dispenser can be modified so that instead of always returning, it signals an exception if a token is requested but not yet available to disburse. The exception signal can include information about the time remaining before the token becomes available. The caller can then decide what to do (the policy). In this setup, a "policy" is just a function that takes the exception signaled by the token dispenser and does something (waiting for the specified time then requesting another token, signalling an error, returning NULL, writing to a log, etc.).
Right now the
token_dispenserwaits as necessary, enforcing the rate limit by pausing. But it's conceivable that a programmer might also want the option of dropping calls to enforce the rate limit, never pausing. As an example, these guidelines for the Mapzen autocomplete function, which link to an interactive demo comparing javascript'sthrottle()anddebounce().To implement this, the
token_dispensercan be modified so that instead of always returning, it signals an exception if a token is requested but not yet available to disburse. The exception signal can include information about the time remaining before the token becomes available. The caller can then decide what to do (the policy). In this setup, a "policy" is just a function that takes the exception signaled by the token dispenser and does something (waiting for the specified time then requesting another token, signalling an error, returningNULL, writing to a log, etc.).