- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 May 2016 10:45:26 +0000
- To: public-web-nfc@w3.org
Your second bullet may not be the best example, but you're basically preparing a branch point in advance, depending on what target is tapped by the user, and you say the script needs to be ready for either. I haven't seen use case like that so far, and doesn't seem to be wide-spread or high priority use case, especially for v1. It also has an uncertainty built in, and contemporary UI designs will almost certainly split this use case into two separate user interaction branches. When a script implements an interaction use case, it almost certainly will be well defined with a given target, specifically for tags, specifically for peers, or the same data either to tags or peers, but I see very, very small likelihood for needing two parallel slots just in case. But even when such parallel slots would be needed, why would they be classified by target only? You could have parallel slots based on other things as well, like script origin, permissions, etc. Then we'd need to update the spec with a more generic algorithm handling generic parallel push slots, exactly like how watches and dispatching are specified. I suggest we start with single push slot (tag, peer or any), and defer the rest for v2. -- GitHub Notification of comment by zolkis Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/102#issuecomment-216195950 using your GitHub account
Received on Monday, 2 May 2016 10:45:28 UTC