[reSIProcate] Proposed DUM Changes to Queue Offers

[Jason Fischl]

On 7/31/06, Scott Godin <slgodin at icescape.com> wrote:
>
> This change does not mean that the application cannot continue to control
> when it requests something.
>
> Also - Currently there are also some conditions  where it is impossible for
> an application to control queuing.   For example:  if you are using session
> timers, then DUM will take care of sending the session refreshes.  The
> application is unaware of this – so it may try to call provideOffer while a
> refresh is in progress – which will cause an exception to be thrown.  Let's
> say you decide to queue the request in the application at this point.  In
> most cases a session refresh will complete without any notification to the
> application – in this case the application will NOT know when it is OK to
> try and retry the provideOffer call – it will need to resort to some kind of
> polling attempt mechanism.
>

It is reasonable to allow queueing of exactly one offer if the
following is true:
- you are not waiting for an answer
- you have replied to all offers (no unanswered offers)

This allows us to handle the situation above where dum is sending or
responding to a session timer when the application calls provideOffer.