Need to review the algorithms for creating a new environment settings object

[mkruisselbrink]

In the Run Service Worker algorithm we create a new environment settings object for the worker. But the algorithms we define for that settings object don't entirely match the algorithms the HTML spec expects a settings object to have. The version in the v2 spec seems at least somewhat better than the version of this algorithm in v1, but I'm not convinced either of them is entirely correct.

[annevk]

We already split the specification into versions? Oh geez...

[annevk]

Who thought that was a good idea for interoperability?

[jungkees]

I believe you also remember we discussed about moving this to CR from long back. Branching V1 is needed for it while we still work on adding stuffs.

I'll apply the V2 changes of the Run Service Worker algorithm to V1 and fix them further with the latest HTML changes around the global concepts. I put them only to V2 then since it was about the worker type classic/module change that I wasn't sure it's also for V1 by that time. This is the only difference except the additional features.

[annevk]

I believe you also remember we discussed about moving this to CR from long back. Branching V1 is needed for it while we still work on adding stuffs.

Still seems like a bad idea given that we have limited resources.

[domenic]

It's probably better to just abandon v1 and not work on it further. It can advance through the dead standards track as long as everyone knows not to try to implement from it.

[jungkees]

The contributors have committed to this standards track work since long ago and discussed during the last f2f in Seattle to move V1 to a CR right after this year's TPAC. There's no difference between V1 and Nightly except the algorithm mentioned in this thread and those added only to Nightly. That is, V1 features are what browsers currently implement and ship. V1 will serve as a stable snapshot for the features that it currently covers.

[annevk]

"Stable" is not a thing in standards. All of it requires ongoing maintenance and refactoring. We shouldn't delude ourselves that this is not the case. You are of course free to allocate your time as you wish, but from experience I can tell you that maintaining two versions, while having to do refactoring, fixing issues, etc. is not really workable if you want to get things done.

[jungkees]

I think maintaining a living standard is analogous to committing patches to the tip-of-tree of a software repo. Ongoing maintenance and refactoring on it is absolutely natural and what we should pursue. Isn't publishing a snapshot of a standards work something similar to shipping a certain version of a software so we can reference the milestone?

[annevk]

Yeah, if standards had the resources software teams have that might be reasonable. We are however pretty far removed from that. Basically the standards version of the platform cannot really run/ship so needs to focus on catching up first.

[domenic]

Isn't publishing a snapshot of a standards work something similar to shipping a certain version of a software so we can reference the milestone?

I think it would be analogous to maintaining Chrome version 1 for a couple years. Nobody does that; instead the master branch is where all work takes place. Sometimes critical security fixes are backported to a previous version of the software. But only if people are currently using it---and nobody is currently using service workers v1. All implementers know that you should only look at the master branch of specs.

[jungkees]

I think your explanation is true from the aspect of using a spec as a reference of an ongoing implementation. But a snapshot - V1 - would also perform a role in providing a milestone which different products (in their own pace) can reference to among each other. Not all the browsers can always ship the latest features in a spec in the same pace.

[slightlyoff]

We're going to do a V1. It's going to be a stable snapshot that can get patent protection, which an unversioned copy simply can't.

If the WHATWG camp has a solution to patent cover, would love to hear it. Until then, can we focus on what algorithms need to be updated? Thanks.

[domenic]

@slightlyoff I'd appreciate if you didn't make this about camps. Nobody brought up such artificial divisions until you did, and it isn't conducive to productive conversation.

What we're trying to discuss here is whether v1 needs to be updated. You haven't explained why it should be (patent coverage is unchanged).

[slightlyoff]

I think the question here is "does v1 need to be updated in order to support changes required to finish it off?". I'm fine with us back-porting the algorithms in question to support that.

[jakearchibald]

Pre F2F notes: seems like a spec wording issue. But do we want to backport this to v1?

[jungkees]

We already backported it to V1: 5d19151. The last bit - referrer policy language adoption - is being tracked in #834.