Re: [w3ctag/spec-reviews] Budget API (especially reserve() method) (#169)

Thanks Alex! Answers below (including a couple TODOs for us and questions for peter)

1) TODO: Linking to the explainer and use cases
2) That readme *is* the explainer, would renaming it that solve this?
3) I'm not aware of any plan to add an observer/event for when budget changes. I imagine that could be useful for a site that gains some budget and can now schedule a background update. Peter - WDYT?
4) The spec says that operation names should be consistent with Permissions API where they are the same, but for those that don't make sense in the Permissions API is there a recommendation for a place for such a registry to live? Could we define this spec as the registry for such background actions?
5) TODO: Mention some other designs we considered in the explainer
6) It seems overly specific to me for us to define convenience function for the # of a single given operation that can be reserved in the future at a given time. It's also not complex to do and people may want to instead know how they can combine various operations etc which complicates things, so I suggest we don't add anything there.
7) Returning remaining budget in calls to `reserve` complicates the return value which is a simple boolean today, and I'm not sure it's worth it given how easy it is to just call `navigator.budget.getBudget()`
8) ¯\_(ツ)_/¯ to why this API isn't marked as available on secure origins only. Peter - is there any reason to allow this on insecure origins?
9) RE: which other operations/APIs are expected to be supported - I don't think we need to be proactively looking to have other specs integrate, unless they are defining some kind of ability for a site to run some code in the background while the user's not on the page. In the future we could consider expanding this concept to cover other non-background resource allocation, but I think that's a non-goal for now.
10) RE: making a per-operation-type budget instead of a global budget, do you have thoughts on this Peter?
11) TODO: define what error will be provided for unsupported operations

Meta-comment: it was fairly hard to go through this feedback and reply to it, this format seems like a fairly challenging one for having these discussions. Finding ways to make TAG reviews easier would be helpful, even if it's just numbering questions so they can be referred to later in the discussion etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/169#issuecomment-295574352