Re: [discovery-api] loophole in current getNetworkServices flow

Jean-Claude Dufourd wrote:
> It seems to me there is a loophole in the current getNetworkServices flow.
>
> After a call to getNetworkServices, the successCallback is called, and a
> NetworkServices object is provided.
> Then I can set onserviceavailable of that object to a suitable Event
> Handler.
> What if a service becomes available between the time the NetworkServices
> is created and the time I set onserviceavailable ?
> The underlying implementation has no way to know whether I am not
> interested in new services or if I did not have time to set the handler
> yet.

I see your point and this is a common misunderstanding of the timing 
involved in registering and ultimately dispatch events in JavaScript 
engines.

If the getNetworkServices() algorithm stalls while waiting for user 
authorization then the state of servicesAvailable could change while we 
await user authorization. However, at that point, the NetworkServices 
object has not yet been provided to the web page via the 
successCallback. That all happens synchronously once the user completes 
their authorization request and sets the initial state of the 
NetworkServices object to return (i.e. amongst other things, setting the 
servicesAvailable attribute to the current number of services that match 
the requested service type token(s) in the initialized NetworkServices 
object at that particular point in time).

We then rely on a concept of queuing events using well-defined concepts 
that determine when events will subsequently fire. Typically we place 
events on a task source's queue which only gets drained when the current 
script block runs-to-completion.

What run-to-completion means is that the browser will execute all code 
in the current script block until that code block ends. Then the JS 
engine will drain any and all task source queues we may have built up 
mostly to actually fire any events placed on those task source queues.

The upshot of this is that if you register an event handler as a result 
of the call to getNetworkServices's successCallback firing (or any 
sub-functions called from therein) any and all events received from the 
platform will be queued and only fired after the script block completes 
execution and all event handlers in that script have been already 
registered.

Thus the situation you describe cannot really happen :) It's not a 
particularly straight-forward solution but it is the standard practice 
in firing web events and I believe the spec is adhering to this process 
as it should.

Best regards,

Rich

Received on Wednesday, 27 February 2013 14:59:14 UTC