Re: [reSIProcate] Proposed DUM Changes to Queue Offers
On 7/31/06, Scott Godin <slgodin@xxxxxxxxxxxx> 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.