-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fetchLater() API (previously: PendingBeacon API) #85
Comments
How does this relate to Beacon API? Why is it a separate spec and not an extension of Beacon API? Also on first glance, this is a lot more complicated than Beacon API itself, which is just one method, not a class hierarchy of multiple interfaces. Is the extra complexity actually necessary? At first glance, it's not obvious why it is necessary to have all these ways to customise a "pending" beacon when regular beacons don't need these things. (If Beacon API itself is underpowered, then that would be more reason to extend the Beacon API instead of making an orthogonal API). |
Also needs to be examined to see if it enables cross-site tracking. |
I'll try to answer some of your questions. Feel free to add more under https://github.com/WICG/pending-beacon/issues so that more pepole can discussion
At the beginning there were discussions around the following options
1 and 2 have its own drawbacks, and the 3rd one is chosen. @fergald might be able to provide full context.
It's answered in WICG/pending-beacon#59. In short we would like to provide more type safety on compile time.
|
The scope of this API proposal doesn't include cross-site tracking. Also cc @fergald |
@othermaciej pinging for any updates or comments |
Friendly pinging again for your position.
In addition to the above reasons from #85 (comment), we further added a section to explain why not extending the Fetch API (Beacon API is roughly equivalent to Fetch |
I’m also concerned about adding an entirely new API.
sure, but I’m wondering if all possible options have been explored for extending the existing spec? For instance, perhaps a third argument could be added to sendBeacon() accepting a dictionary that:
Perhaps something like the above could addressed the use cases without needing an entirely new API? |
Just also want to clarify that the feedback isn’t specifically about the API shape, but rather the maintenance of the existing specification and infrastructure. Forking a new spec would be quite undesirable because the existing beacon spec is already not well maintained (I.e., now we have two problems). Echoing @othermaciej, we’d rather see the standards community work on updating what already exists specs than introduce something new that mostly replicates and extends existing functionality. It could also help address issues raised by Mozilla folks too. Adding “venue” as a concern, as doing this work in WebPerfWG may be preferable. |
@marcoscaceres Thanks for the response. We'll update the explainer to explore modifying sendBeacon however I don't think adding an AbortController can meet the requirements. As well as being able to abort, being able to tell whether the payload has been sent already is a key feature, without that it's impossible to accumulate data and avoid resending. That requires something that's accessible and represents the beacon pending state. We could provide a way to supply a callback to be called if the beacon is sent and the caller could then track that state but ergonomically that seems poor. An alternative would be to have sendBeacon return an object instead of |
In terms of spec mechanics and venue, the WebPerfWG have been talking about potentially adopting this API and merging it into the beacon spec. If we have y'all's support for this, we can easily do that. In terms of API shape, @fergald led a few interesting discussions (at TPAC, as well as before and after) about the API at the WG, which led to the current proposal. As Fergal said, there are significant differences between IMO, trying to cram everything into a single API would only lead to confusion (and I'm not even sure what that would look like). At the same time, if y'all want to have a high bandwidth discussion about that at the WebPerfWG, I'm more than happy to facilitate that. |
The WebPerf WG has historically done a poor job of Fetch integration. Getting that done correctly is somewhat vital for this API. The note in the draft is not reassuring. I filed WICG/pending-beacon#63 on that. Some of @domenic's ideas on sharing more API surface in WICG/pending-beacon#52 (comment) make sense to me, but if maintenance is not centralized that still seems like a danger zone (see Cache API). (The API also seems like too much a departure from |
I guess it depends on what the goals are. If one of the goals would be to keep this new API backwards compatible, then one could add the optional third argument with the fetchOptions dictionary @domenic suggested and perhaps change the return signature to a
Then one can add something like Anyway, point being, it's good having a set of agreed upon goals requirements and hopefully getting general agreement that (API shape aside!) "Pending Beacons" as a general concept are a desirable thing we want to collectively add the the Web Platform. At the same time, the concerns that @annevk and I have raised about integration, maintenance, and venue need a concrete plan that we (WebKit) can be confident in. I think we will get there, but just need to work out the details. Give us a few days to discuss the general idea amongst ourselves and we will get back to you soon with a position (and hopefully a path forward to collaborative on making something great). |
After consideration and discussion with colleagues, we express our tentative support for the standardization effort with some concerns, as indicated by the GitHub labels. To collaboratively address the concerns:
Our colleagues and others in the WebKit community may have additional points to raise. If not, we will consider this position to be "supportive" within the next week or so. |
@marcoscaceres Could you help clarify the integration here? Thanks! |
Not necessarily. It's more that we have those two specs (Beacon and Fetch) already and, irrespective of API shape and new functionality, this new proposal has to integrate with both of those APIs: the existing spec infrastructure. We know there is new functionality being added, but it's still going to have to go into the algorithms of fetch in particular, and hopefully into the existing algorithms of the Beacon spec. If it doesn't, then that would be somewhat weird given it's a "beacon" even though it's "pending". Further, if we end up with a new spec, it means that Pending Beacon might not benefit from enhancements made to either Fetch or the existing Beacon spec. That's why we want it integrated into either of the existing specs.
That's correct (even if it's a super special fetch that survives a browser crash or whatever).
I don't have any further comments about the API shape at this point - but we've outlined some of the problems already. For instance, this isn't an API where developers will create unlimited instances of an object: it's going to be heavily restricted to a couple of requests, maybe even just 1, and probably at most 2? (i.e., a Further we have an existing API shape ( |
This summarize the discussion from WebKit/standards-positions#85 (comment) and also potentially unblocks the need to add custom headers in WICG#50
Address comments from #68 Also a follow up to #50 and WebKit/standards-positions#85 (comment)
An update proposal is shown in this video. We should probably engage in the appropriate forum. |
There is an ongoing discussion about fetch based API proposal. Please take a look at the main thread WICG/pending-beacon#70 and this list of discussions https://github.com/WICG/pending-beacon/issues?q=is%3Aissue+is%3Aopen+label%3Afetch-based-api |
We put forward a proposal that would remove a number of our concerns here and would make us supportive of this effort: WICG/pending-beacon#70 (comment). |
Marking as support given the progress made... |
Note: the PendingBeacon API has been evolved to a fetch-based approach, and the latest discussions happen in whatwg/fetch#1647 |
Request for position on an emerging web specification
Information about the spec
Design reviews and vendor positions
Anything else we need to know
We would like to have feedback from WebKit about this API before finalizing its shape and behavior.
The text was updated successfully, but these errors were encountered: