wicg / budget-api Goto Github PK

From TAG feedback issue

Some operation names are common with the Permissions API. It'd be great to understsand how these will be maintained and kept in sync as new operations are added. Should the TAG be assisting?

Are there going to be operations that will be budget-able but wouldn't also be introspectable via the Permissions API? As registries are an open problem for web specs, we'll ping back when we come up with a solution.

From TAG feedback issue

@torgo mentions that the Security and Privacy considerations section might want to include notes about what this API behaves when in private browsing mode. Specifically, advice for authors of specs that will integrate with Budgets

From TAG feedback issue

getBudget() appears to be global and not a per-operation-type budget. Have you consulted with other browsers to ensure that this is a reasonable design choice for their implementations? This has been a source of difficulty for storage quota in the past.

From TAG feedback issue

Would be great to have the spec link directly to the explainer.

Might not be an issue, but just double check the links in the various documents. I just fixed the one in the readme that was pointing back to your gh account.

From TAG feedback issue

What error will be reported for unsupported operations?

From TAG feedback issue

@triblondon notes that the model the API presents weights all silent pushes (e.g.) to be equal. Do we have confidence that this will always be true? Has a model been considered in which the developer requests some budget for an operation and is then limited to that budget (e.g., execution time)?

https://wicg.github.io/budget-api/#dom-budgetservice-reserve

"run the following steps in parallel" comes before any of the steps of the algorithm. Because the entry settings object does not stay constant, in a pedantic reading it's not clear when it should be evaluated.
Chromium's implementation goes async after the SecurityError exception handling, and that would make sense for the spec as well.

Because this API relates to the ability to do work in the background, which is considered a privilege, functionality provided by this API is only available in a secure context.

I don't think this API itself should be limited to use in secure contexts. It would make more sense if you weren't in a secure context that the API exists but reports that there was no available budget for a particular action requiring a secure context.

Given intent to remove from Blink, should this repo be archived? https://groups.google.com/a/chromium.org/d/msg/blink-dev/18r3whCBv0I/b8qrtFTsDAAJ

https://wicg.github.io/budget-api/#navigator-budget-interface

If so, bless it with [SameObject].

Sorry, this is bikeshedding, but we talk a lot about "budget" on the web... like:
https://timkadlec.com/2014/11/performance-budget-metrics/

And with the Web Payments API starting to ship, there might be some confusion about what this API is about. I've had my head in Web Payments for the last week, so I instantly thought "wait? what? budget for payments?" 🤑

It might be good to qualify the name somehow.

getBudget should be documented as returning the amount of budget that there is expected to be assuming the user doesn't interact with the site at all in the meantime (i.e. a weak lower bound, though it's possible the budget will go below the prediction if e.g. the user revokes a permission for the website).

Otherwise UAs can't make reasonable predictions, and getBudget would be less actionable for developers.

Currently it says:

A background operation is the ability for an origin to execute potentially resource consuming code in the background.

I think the definition should explain what a background operation is and maybe list some examples. This feels like it's instead defining a background operation budget. Specifically I don't think a background action is an ability but it's a concrete action where as a budget would measure the ability to perform actions.

I found it difficult to understand the spec the first time around because this definition is the underpinning of the specification but it doesn't really explain what a background operation is. I was wondering if we were including any events (input, timeout, request animation frames) and if they were measure by count, cpu time, wall time.

Is there any updates on budget api ?
I wanna know about current status of budget api (actually silent push).
so someone could summaries about status of this proposal ?
(mozilla says this seems abandoned mozilla/standards-positions#73 (comment))

Adding this to the W3C IRP manager... Some new files will appear in the gh-pages branch.