Re: [web-nfc] Review fixes for #44.

>

> >       • What's the rationale for the 10s limit on a push timeout? I'm
> interested in an app where a user can enter information into a webpage
> that's continuously primed to send that information (directly or as a URL)
> to an NFC peer, without a "send" button having to be pushed prior. To make
> this work with the current spec, I'd have to code a push loop. What's the
> problem with an infinite timeout when a push is only active while its page
> is open and in focus, and when cancelPush can be called?
>
> Fixed by making the default value implementation-dependant:
>
>
> https://github.com/zolkis/web-nfc/commit/57d0487d0e93ad0df7d09588980ac9f940b412e3
>
> For this change, we need to gather further feedback from implementers,
> consider whether not specifying the default will degrade the user
> experience.
>
>
This does not fix the use case above, which wants a value that does not
result in a timeout at all (like 0).

Now what happens if the developer sets a timeout of a 1000 seconds, but one
browser times out after 10 seconds, another after 60, etc, but in no case
meeting the developer expectation? This behavior should be standardized,
and saying there is a timeout, which is platform dependent can only be
accepted if developers can learn from somewhere what exactly that default
timeout value is on every browser. Since this is not going to happen, this
solution is not good at all.

Otherwise, it is much better to bind the timeout to the user interaction,
i.e. the time needed to do one gesture, targeted for a specific operation
with a specific permission. In Web NFC case, that would be a few seconds.
The question is whether do we accept 0 as a special value to work without a
timeout. The default value could have stayed at 10 seconds.

Regards,
Zoltan