Re: [ServiceWorker] Add cookie accessor/setter methods? (#707)

Given that, async map with full access to exactly the same data as
document.cookie with no new functionality (e.g. it would reveal on;y names
and values you could see in document.cookie, and setting would allow you
the same domain, path, name, value, maxage, secure, httponly and even
expires control [the cookie expiration may in fact need to be a precise
date and time!) and no new functionality (e.g. reading interface only
exposes in-scope cookie names and values in the same order as
document.cookie and does not tell you their domain, path, expiration time,
or secure flag) and just a cleaner API (no string parsing, no
concatenation, allow a date object for expiration) would seem to me like
the obvious starting point.
On Jun 10, 2015 15:52, "Alex Russell" <notifications@github.com> wrote:

> A few points:
>
>    - having access to cookies is a no-brainer. We can't prevent it (if
>    there's a document, there's an API that already does it already); can we
>    just get over our bad selves and get on with a design that does cookies
>    better?
>    - extra restrictions over what the current API can do need to be
>    justified; the burden of proof is on removal, not equality of functionality
>    - setting should be symmetric; if reading is async, setting should be
>    too
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/slightlyoff/ServiceWorker/issues/707#issuecomment-110940363>
> .
>


---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/707#issuecomment-110991693