Collaborate with existing proposal?

[domenic]

I wanted to connect you and @bsittler who is working on https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md . In particular his proposal includes an observer API at https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md#monitoring .

[bsittler]

Thanks, @domenic ! I'm looking at @patrickkettner 's specification and I like what I see - it seems like this specification exposes a lot more of the "why" of cookie changes than I proposed exposing my explainer, and that may be a good thing. Although this "why" information is not reliably available to web applications today, exposing it might be a useful thing.

[bsittler]

I just raised #32 to address cookie change access from Service Workers specifically.

[patrickkettner]

Hey fellers,
I am more than happy to help collaborate on your spec, and I am very happy to see you offer feedback on mine. In talking to @aliams about this, he brought up some concerns that y'all may have about there being two competing specs and so I wanted to write out my thinking on that as of now.

At a core level, I think the goals of the two are pretty far apart. This spec is only intended to be a thin layer of sugar over the cookie (no pun intended) and a single change event. Whereas @bsittler's is more of a "what if we designed document.cookie from scratch". Both have a huge amount of value, and I think they can and should both coexist.

We have seen at a number of sites, both large and small, the pattern of polling a cookie over and over again in order to ensure multi-tab/window users don't get into a bizarre state. This, along with very thin wrappers like js-cookie make up most of the interactions that I see folks make with document.cookie. This is the entire reason for this spec. It is an attempt to standardize the behavior that is already being leveraged in the browser extension world (cookie.onChange has been around for ever in firefox extensions, chrome as well).
I know that the observable pattern that async-cookies implements would be a solution to that, but realistically few web developers is going to fork their logic in their session handling to support an observer or promises when they are doing polling today. Some certainly will, but a majority will not. A single event that can otherwise wrap their existing logic has a much lower overhead and implementation cost (for web devs, and implementers alike).

From my point of view, the benefit that is gained from async-cookie is the fact you have access to cookies from outside of the document interface, not the observable behavior. When developers are implementing worker based code, they will have the ability to interact with cookies without having to resort to header inspection - which is awesome! As a developer I can't wait for that type of thing to exist. But by the same token, if I am not using a service-worker, or don't want to maintain the logic for my session handling inside of a service worker (if it is cookie based, and I need to support iOS this is a must) than I am almost certainly going to continue to use the document interface exclusively.

I think that both specs have their own strengths, and implementing one will not take away from the value of the other.

cool?