W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] HTML Cookie API

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 26 Feb 2010 14:44:43 -0800
Message-ID: <63df84f1002261444y27abd157jfbd901db3f122cc2@mail.gmail.com>
On Fri, Feb 26, 2010 at 12:20 PM, Darin Fisher <darin at chromium.org> wrote:
> On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende <dresende at thinkdigital.pt>
> wrote:
>>
>>
>> > ? ? ? ? No. pushCookies would be a way of pushing cookies to the
>> > ? ? ? ? current js and
>> > ? ? ? ? then you could call getCookie several times without defining a
>> > ? ? ? ? callback.
>> > ? ? ? ? It would be almost like:
>> >
>> > ? ? ? ? ? ? ? ?document.observe("cookieload", myAppLoad)
>> >
>> >
>> > Right. ?My point was that you could implement pushCookies on top of
>> > Adam's API.
>> >
>> >
>> > -Darin
>>
>> Agree. Just like you could implement Adam's API on top of current
>> browsers cookies spec :P
>>
>
>
> No, I don't think that is possible. ?Adam's spec reveals a lot of extra
> information that "document.cookie" does not return. ?For example, it exposes
> domain and expiry information.
> But, I think your point was that it would be possible to simulate an
> asynchronous API on top of a synchronous one. ?I agree that is possible, but
> it would not perform very well.

Another problem is that some current browsers do not implement
document.cookie in a non-racy way. So while you could implement Adams
API, you couldn't guarantee that it wouldn't be racy. However
implementations should be able to implement Adams asynch API with no
race problems.

/ Jonas
Received on Friday, 26 February 2010 14:44:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC