Add an algorithm of storage maintenance (IG Cap).

[qingxinwu]

It includes several IG caps.

Also link "user agent" to Infra's [=user agent=].

---

Preview | Diff

[qingxinwu]

@orrb1 PTAL. Thanks! Not sure why I cannot add you to the reviewers.

[orrb1]

Thank you, @qingxinwu!

[qingxinwu]

@domfarolino Should we define these numbers as "Vendor (or Implementation) Specific Values" as some specs do? I'd think so, since we're fine with vendors choose their own numbers for these, instead of sticking with our pick.

[domfarolino]

LGTM % discussion in https://github.com/WICG/turtledove/pull/859/files#r1357262550, which I'd like to understand better.

[qingxinwu]

LGTM % discussion in https://github.com/WICG/turtledove/pull/859/files#r1357262550, which I'd like to understand better.

How about this comment about defining the limits as "vendor specific values"? We also want to provide our limits as an example for people to start with if they want, so wondering what would be the best format/wording (e.g., an "Example" with our numbers, or "Note" for that, etc.)

[domfarolino]

How about #859 (comment) about defining the limits as "vendor specific values"? We also want to provide our limits as an example for people to start with if they want, so wondering what would be the best format/wording (e.g., an "Example" with our numbers, or "Note" for that, etc.)

Hmm, so there seems to be two places where we might want to introduce implementation-defined "looseness" around IG size, and I'm not sure what the difference is:

• Make the calculation of estimated size have a bunch of implementation-defined padding and be non-specific
  • That seems to be what https://github.com/WICG/turtledove/pull/859/files#r1357262550 centers around, and mentions that the implementation does(?)
• Making the predefined constants implementation-defined, instead of mandatory values:
  • Add an algorithm of storage maintenance (IG Cap). #859 (comment)

Are both of these desirable? Or are both of these just different ways of achieving the same thing?

[qingxinwu]

How about #859 (comment) about defining the limits as "vendor specific values"? We also want to provide our limits as an example for people to start with if they want, so wondering what would be the best format/wording (e.g., an "Example" with our numbers, or "Note" for that, etc.)

Hmm, so there seems to be two places where we might want to introduce implementation-defined "looseness" around IG size, and I'm not sure what the difference is:

• Make the calculation of estimated size have a bunch of implementation-defined padding and be non-specific

  • That seems to be what https://github.com/WICG/turtledove/pull/859/files#r1357262550 centers around, and mentions that the implementation does(?)

• Making the predefined constants implementation-defined, instead of mandatory values:

  • Add an algorithm of storage maintenance (IG Cap). #859 (comment)

Are both of these desirable? Or are both of these just different ways of achieving the same thing?

They're different things. I'll keep the size estimation part under the other comment (and it turns out that's no longer a problem).

Here, it's about the size limitation an implementation/vendor might want to put on stored IGs, such as total maximum sizes of IGs per owner. We chose our numbers for those limitations, but we'd like to allow other vendors to choose their limitations as they want if their browser can handle more/less limits (e.g., allow storing more IGs per owner, give higher storage limit per owner, etc.), and our numbers are examples and start point for them. If they'd like to use the same numbers, that's fine as well.

[domfarolino]

We chose our numbers for those limitations, but we'd like to allow other vendors to choose their limitations as they want if their browser can handle more/less limits (e.g., allow storing more IGs per owner, give higher storage limit per owner, etc.), and our numbers are examples and start point for them. If they'd like to use the same numbers, that's fine as well.

OK thanks for clarifying. In that case, I'd say something like:

Implementations may define their own values for the below constants, however we supply the below values as a starting point, inspired by what the initial implementation of this specification uses:

That can go above the definition of the constants you define. Does that make sense?

[qingxinwu]

We chose our numbers for those limitations, but we'd like to allow other vendors to choose their limitations as they want if their browser can handle more/less limits (e.g., allow storing more IGs per owner, give higher storage limit per owner, etc.), and our numbers are examples and start point for them. If they'd like to use the same numbers, that's fine as well.

OK thanks for clarifying. In that case, I'd say something like:

Implementations may define their own values for the below constants, however we supply the below values as a starting point, inspired by what the initial implementation of this specification uses:

That can go above the definition of the constants you define. Does that make sense?

Done. That sounds great. Thanks

[JensenPaul]

I gave this a quick review and it LGTM.