Should there be two pushMessage methods or not

[kenchris]

https://github.com/w3ctag/spec-reviews/blob/master/2015/10/nfc-feedback.md

pushMessage can only have two active pushes happening at once--one for tags, the other for peers. Is this a list expected to expand? If this is a fixed set of things, then could the API be simplifid by having separate pushToTag() and pushToPeer() APIs? (Not sure if this would be a good thing.)

[zolkis]

Yes, IMO this would make things more clear for developers, at the expense of a longer spec.
See also see this comment in #68.

[jyasskin]

@dontcallmedom suggested in the F2F that we drop the separation between tags and peers. Specifically, NFCPushOptions would lose the target field, and "If there are any existing instance of this algorithm running for the current NFC adapter whose target is equal to options.target" would lose the "whose target is equal to options.target" (and maybe some more cleanup).

[zolkis]

Yes, that is possible as well. After a short check it seems feasible, but we need to dig deeper to find out what functionality/use cases we may lose. We also need input from developers for that (@mrj ?).

We can deal with this after figuring out the multiple adapter handling (behind the scenes), and getting rid of explicit adapter objects (#67).

[zolkis]

It is clear that we will lose the ability to tell "push to peers but not to tags", which may be important in some cases, but it's not clear how important.

Losing "push to tags but not to peers" may also be important, though at the moment I can't see strong reasons for that.

[kenchris]

What about the use case where you want to push different date depending on it being a peer or a tag, which would be common as peer-to-peer could be for app-to-app communication instead of just storing data

[zolkis]

Because all dev experience with (native) NFC handles peer and tag communication separately, merging them is a bold step. I think we need to experiment with this. IIRC at least @mrj had a use case with peer-only, so I would keep the separation a bit longer, and keep this issue open.

[zolkis]

To summarize, we want to:

1. Simplify the way push() is called, and not care if the push message refers to tag or peer: whichever is tapped first, the push happens there.
2. Still maintain possibility to say that the push message is meant only for tags, or peers.

One solution is to reintroduce "any" as NFCPushTarget value, and make it default.
@jyasskin you have had some issues with the value "any" (or the related steps) in the past, but I don't recall what it was. I will try to use it again and let's see if I can formulate the steps well.

[zolkis]

The above also means we stay with one push() method for now.

[zolkis]

Fixed by #88. We stay with one push() method for now.