Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:49 PM, Darin Fisher wrote: > Some other random comments: > 1- Perhaps deleteCookie should also take an optional error callback. Done. It's a bit strange, but deleteCookie can fail in third-party contexts. > 2- Is it possible for setCookie to be used to set a http-only cookie? That > could be an interesting use case. Some browsers allow this, but others don't. IMHO, it doesn't matter much for security, but some folks think that it does. Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 6:08 PM, Adam Barth wrote: > On Wed, Feb 24, 2010 at 5:00 PM, Nicholas Zakas > wrote: > > Even though there can be multiple cookies with the same name on a single > document, this most frequently occurs due to error rather than intention. > I've never received a YUI bug report about this occurrence though I have > considered returning an array of values instead of just the first value in > this case. I might just go do that now. :) > > > > My initial comment still remains: retrieving the value of a single named > cookie seems to be a much more common use case than retrieving all cookies. > You can choose to solve the duplicate cookie name issue in a number of ways, > but not providing a way to access a cookie by name seems like a flaw in this > design. > > Done. I've made the API return the first cookie that matches the > specified name. If a web developer wants to get all the cookies, I've > added a getAllCookies() API. > > Adam > Some other random comments: 1- Perhaps deleteCookie should also take an optional error callback. 2- Is it possible for setCookie to be used to set a http-only cookie? That could be an interesting use case. -Darin
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 5:00 PM, Nicholas Zakas wrote: > Even though there can be multiple cookies with the same name on a single > document, this most frequently occurs due to error rather than intention. > I've never received a YUI bug report about this occurrence though I have > considered returning an array of values instead of just the first value in > this case. I might just go do that now. :) > > My initial comment still remains: retrieving the value of a single named > cookie seems to be a much more common use case than retrieving all cookies. > You can choose to solve the duplicate cookie name issue in a number of ways, > but not providing a way to access a cookie by name seems like a flaw in this > design. Done. I've made the API return the first cookie that matches the specified name. If a web developer wants to get all the cookies, I've added a getAllCookies() API. Adam
Re: [whatwg] HTML Cookie API
Even though there can be multiple cookies with the same name on a single
document, this most frequently occurs due to error rather than intention. I've
never received a YUI bug report about this occurrence though I have considered
returning an array of values instead of just the first value in this case. I
might just go do that now. :)
My initial comment still remains: retrieving the value of a single named cookie
seems to be a much more common use case than retrieving all cookies. You can
choose to solve the duplicate cookie name issue in a number of ways, but not
providing a way to access a cookie by name seems like a flaw in this design.
Of course, if the main use case you're concerned about is retrieving all
cookies, then feel free to disregard this feedback.
-Nicholas
__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Wednesday, February 24, 2010 1:07 PM
To: Nicholas Zakas
Cc: Darin Fisher; whatwg
Subject: Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is why
> I wrote the YUI Cookie utility way back when). The thing that seems to be
> missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using your
> API, getting the value of a single cookie with a known name becomes:
>
> document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
> });
>
> That seems like a lot of work just to retrieve a single cookie value.
The problem is there can be multiple cookies with the same name for a
given document. The YUI Cookie utility seems to assume there's only
one. We could add a facility for filtering the results of getCookies,
but that's easy enough to do correctly in JavaScript.
Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith wrote: > On Wed, Feb 24, 2010 at 4:17 PM, Adam Barth wrote: >> On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith >> wrote: >>> Instead of "array like", I would like to rather have a NamedCookieMap, >>> which is sort of like a NamedNodeMap that the cookies can be retrieved >>> by an item or namedItem. >> >> That API design assumes that there's only one cookie with a given name >> in each cookie-string. Unfortunately, that is not a valid assumption. > > That is only true in that that example assumes that each cookie is > named. It would be entirely possible for the value to be instead a > collection, as in: > > var x = document.forms[0].elements["radioName"] > > - and the result is that x could be either an element or a collection > of elements. That seems more complex than just providing a list of cookies. >>> Where is the argument for making the API async? >> >> Please see the discussion earlier in this thread. >> > Can you be more specific? I see: > > | I really think the API should be asynchronous, as to avoid the mess > | that .localStorage currently is. > > But I don't know if that's what you meant by "please see earlier". I mean looking at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/thread.html and reading the thread rooted at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025300.html. In particular, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025325.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025326.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025327.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025331.html Those messages also refer to thousands of messages about localStorage. All the synchrony issues with localStorage recur here. >>> Cookies have been synchronous for longer than I have been writing >>> javascript and to my knowledge, nobody has ever complained of that >>> being a problem. >> >> In fact, I've heard a great many complaints about this recently >> (particularly from Darin Fisher), which is part of what prompted me to >> make this proposal. > > Is there a link to that? I missed it. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025326.html ... plus personal communication. >>> Asynchronous cookies that would mean that cookie setting tests would be >>> harder. >> >> No one is suggesting removing the current document.cookie API. > > Nobody is suggesting you change your tires. Why bring it up? This API does not make it any harder to test whether setting a cookie works because you can still use whatever test you like. If we want to solve the problem of making cookie feature testing easier, we can do that. Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith wrote: > >> Where is the argument for making the API async? > > > > Please see the discussion earlier in this thread. > > > Can you be more specific? I see: > > | I really think the API should be asynchronous, as to avoid the mess > | that .localStorage currently is. > > But I don't know if that's what you meant by "please see earlier". > There have been numerous messages (well over a dozen) discussing this. If you don't see them, try checking online archives, waiting for their delivery to your mailbox, or similar. > >> Asynchronous cookies that would mean that cookie setting tests would be > harder. > > > > No one is suggesting removing the current document.cookie API. > > Nobody is suggesting you change your tires. Why bring it up? This response makes no sense at all. You expressed concern that an async API would make particular existing patterns harder to write. The response was that these existing patterns will continue to work because they rely on a synchronous API that isn't getting removed; the async API is proposed as an addition. I have no idea what your retort after that is intended to convey. PK
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:17 PM, Adam Barth wrote: > On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith wrote: >> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >>> The document.cookie API is kind of terrible. Web developers shouldn't >>> have to parse a cookie-string or prepare a properly formated >>> set-cookie-string. Here's a proposal for an HTML cookie API that >>> isn't as terrible: >>> >>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >>> >>> I'd like to propose we include this API in a future version of HTML. >>> As always, feedback welcome. >>> >> | Because HttpOnly cookies are inaccessible to script, the |httpOnly| >> | attribute will usually be false. >> >> Usually? When ever would HttpOnly be true? > > For example, if the HTML document is running with higher privileges > because its effective security origin isn't a (scheme, host, port) > tuple. This can occur, e.g., in Firefox when running with "chrome" > privileges. > >> Instead of "array like", I would like to rather have a NamedCookieMap, >> which is sort of like a NamedNodeMap that the cookies can be retrieved >> by an item or namedItem. > > That API design assumes that there's only one cookie with a given name > in each cookie-string. Unfortunately, that is not a valid assumption. > That is only true in that that example assumes that each cookie is named. It would be entirely possible for the value to be instead a collection, as in: var x = document.forms[0].elements["radioName"] - and the result is that x could be either an element or a collection of elements. >> Where is the argument for making the API async? > > Please see the discussion earlier in this thread. > Can you be more specific? I see: | I really think the API should be asynchronous, as to avoid the mess | that .localStorage currently is. But I don't know if that's what you meant by "please see earlier". >> Cookies have been synchronous for longer than I have been writing >> javascript and to my knowledge, nobody has ever complained of that >> being a problem. > > In fact, I've heard a great many complaints about this recently > (particularly from Darin Fisher), which is part of what prompted me to > make this proposal. > Is there a link to that? I missed it. >> Asynchronous cookies that would mean that cookie setting tests would be >> harder. > > No one is suggesting removing the current document.cookie API. Nobody is suggesting you change your tires. Why bring it up? Garrett
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith wrote: > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. >> > | Because HttpOnly cookies are inaccessible to script, the |httpOnly| > | attribute will usually be false. > > Usually? When ever would HttpOnly be true? For example, if the HTML document is running with higher privileges because its effective security origin isn't a (scheme, host, port) tuple. This can occur, e.g., in Firefox when running with "chrome" privileges. > Instead of "array like", I would like to rather have a NamedCookieMap, > which is sort of like a NamedNodeMap that the cookies can be retrieved > by an item or namedItem. That API design assumes that there's only one cookie with a given name in each cookie-string. Unfortunately, that is not a valid assumption. > Where is the argument for making the API async? Please see the discussion earlier in this thread. > Cookies have been synchronous for longer than I have been writing > javascript and to my knowledge, nobody has ever complained of that > being a problem. In fact, I've heard a great many complaints about this recently (particularly from Darin Fisher), which is part of what prompted me to make this proposal. > Asynchronous cookies that would mean that cookie setting tests would be > harder. No one is suggesting removing the current document.cookie API. You can continue to use whatever cookie setting test you're current using. Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> The document.cookie API is kind of terrible. Web developers shouldn't
> have to parse a cookie-string or prepare a properly formated
> set-cookie-string. Here's a proposal for an HTML cookie API that
> isn't as terrible:
>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>
> I'd like to propose we include this API in a future version of HTML.
> As always, feedback welcome.
>
| Because HttpOnly cookies are inaccessible to script, the |httpOnly|
| attribute will usually be false.
Usually? When ever would HttpOnly be true?
Instead of "array like", I would like to rather have a NamedCookieMap,
which is sort of like a NamedNodeMap that the cookies can be retrieved
by an item or namedItem.
I would also rather like to see a `cookies` getter instead of
getCookies (just personally, style-wise I like that).
// Get a Cookie object or null.
var fooCook = document.cookies.namedItem("foo");
- or -
// Get a Cookie object or undefined.
var fooCook = document.cookies["foo"];
- or -
// Get a Cookie object or undefined.
var fooCookIndex = 2;
fooCook = document.cookies[fooCookIndex];
How about that?
A Cookes API makes working with cookies easier.
Working with cookies is important to support browsers that do not
implement new features such HTML 5 storage APIs.
For legacy browsers, a Cookie API can be easily emulated in script. A
common interface for new browsers and legacy browsers would have
consistent cross browser behavior and little disparity. The same
cannot be said for Storage APIs.
Where is the argument for making the API async?
Cookies have been synchronous for longer than I have been writing
javascript and to my knowledge, nobody has ever complained of that
being a problem. A common feature test is something like:
var isCookieSupported;
if(typeof document.cookie == "string") {
document.cookie = "test=1";
isCookieSupported = document.cookie.indexOf("test=1") !== -1;
}
That feature test relies on the fact that cookies are synchronous. If
the new proposed API is also synchronous, then the cookies feature
test will be possible as:-
var isCookieSupported;
if(typeof document.cookie == "string") {
document.setCookie({name: "test", value : "1"});
isCookieSupported = document.cookies.test === "1";
}
Asynchronous cookies that would mean that cookie setting tests would be harder.
Garrett
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is why
> I wrote the YUI Cookie utility way back when). The thing that seems to be
> missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using your
> API, getting the value of a single cookie with a known name becomes:
>
> document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
> });
>
> That seems like a lot of work just to retrieve a single cookie value.
The problem is there can be multiple cookies with the same name for a
given document. The YUI Cookie utility seems to assume there's only
one. We could add a facility for filtering the results of getCookies,
but that's easy enough to do correctly in JavaScript.
Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 12:44 PM, Nicholas Zakas wrote: > I think there’s always going to be a disconnect between browser developers > and web developers, since we’re both living in very different worlds. > > Like I said, I’m all for making cookie access more rational (as if one could > argue that it has been at all rational to this point). Right now, though, I > can’t see a benefit to switching from any of the current synchronous > approaches to an asynchronous one, as it doesn’t give me enough added > benefit. The added benefits are: 1) Higher performance because your page isn't frozen while the browser jumps across some number of threads and processes to reach the disk. 2) Fewer bugs because you don't have to parse the cookie-string / manufacture a set-cookie-string yourself. > The asynchronous approach may be the most performant and > potentially the easiest to implement, but if it’s out there and everyone is > still using document.cookie, is there really a net gain? Folks who want synchronous access to cookies can continue to use document.cookie. Folks who want to realize the benefits of the new API can use the new API. Sounds like everyone wins. Adam
Re: [whatwg] HTML Cookie API
I think there's always going to be a disconnect between browser developers and web developers, since we're both living in very different worlds. Like I said, I'm all for making cookie access more rational (as if one could argue that it has been at all rational to this point). Right now, though, I can't see a benefit to switching from any of the current synchronous approaches to an asynchronous one, as it doesn't give me enough added benefit. The asynchronous approach may be the most performant and potentially the easiest to implement, but if it's out there and everyone is still using document.cookie, is there really a net gain? -Nicholas __ Commander Lock: "Damnit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Wednesday, February 24, 2010 12:20 PM To: David Flanagan Cc: Peter Kasting; whatwg; Nicholas Zakas; Darin Fisher; Adam Barth Subject: Re: [whatwg] HTML Cookie API On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan wrote: Jeremy Orlow wrote: Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. Well if no one is going to implement the storage mutex, then I probably need to retract my last message But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J I worry that this comes down to web developers who want simple APIs vs browser implementors who say we can't have them (at least not if we also want speed.) Concurrency issues are not my strong suit, but shouldn't it be possible to have safe, synchronous read-only access to cookies (caching volatile values like cookies within each thread and then clearing that cache when the thread returns to the event loop). Can't the requirement for a mutex or an asynchronous API be limited to setCookie()? >From a technical standpoint, this is very doable. And, done right, I think I could be in favor of it. But I believe the counter argument is that any relaxation of run to completion semantics is going to confuse developers and probably result in them writing racy code without realizing it. Many developers won't understand when it's safe to use the cached value vs needing to use the asynchronous interface. And if the less safe one is easier to use I agree that asynchronous interfaces have disadvantages, but as far as I can tell many of them are costs that you pay once (learning them and getting use to them) or once per app (if you handle one asynchronous call or need to use setTimeout, then probably using another won't require too much restructuring of your code). Maybe I'm just a browser developer who's completely out of touch with reality though. :-)
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan wrote: > Jeremy Orlow wrote: > > >> Also note that the spec currently has the notion of a storage mutex which >> should be taken whenever a script tries to access a cookie (or local >> storage) and is held until the script finishes. The network stack is also >> supposed to take this lock whenever getting or setting a cookie. No one has >> implemented the storage mutex or stated any intention of doing so because >> this is basically impossible today. But, if there were an asynchronous API >> that most people were using, it actually could be possible that we'd want to >> implement such a mutex since cookies would then obey run to completion >> semantics without having serious lock contention. >> >> > Well if no one is going to implement the storage mutex, then I probably > need to retract my last message > > > But yeah. Definitely any API that touches information spanning tabs (and >> probably even APIs spanning origins within those tabs) really should be >> designed in an async manor from now on. Otherwise we're just digging the >> whole deeper in terms of forcing ourselves into a single threaded world. >> >> J >> > > I worry that this comes down to web developers who want simple APIs vs > browser implementors who say we can't have them (at least not if we also > want speed.) > > Concurrency issues are not my strong suit, but shouldn't it be possible to > have safe, synchronous read-only access to cookies (caching volatile values > like cookies within each thread and then clearing that cache when the thread > returns to the event loop). Can't the requirement for a mutex or an > asynchronous API be limited to setCookie()? > >From a technical standpoint, this is very doable. And, done right, I think I could be in favor of it. But I believe the counter argument is that any relaxation of run to completion semantics is going to confuse developers and probably result in them writing racy code without realizing it. Many developers won't understand when it's safe to use the cached value vs needing to use the asynchronous interface. And if the less safe one is easier to use I agree that asynchronous interfaces have disadvantages, but as far as I can tell many of them are costs that you pay once (learning them and getting use to them) or once per app (if you handle one asynchronous call or need to use setTimeout, then probably using another won't require too much restructuring of your code). Maybe I'm just a browser developer who's completely out of touch with reality though. :-)
Re: [whatwg] HTML Cookie API
Jeremy Orlow wrote: Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. Well if no one is going to implement the storage mutex, then I probably need to retract my last message But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J I worry that this comes down to web developers who want simple APIs vs browser implementors who say we can't have them (at least not if we also want speed.) Concurrency issues are not my strong suit, but shouldn't it be possible to have safe, synchronous read-only access to cookies (caching volatile values like cookies within each thread and then clearing that cache when the thread returns to the event loop). Can't the requirement for a mutex or an asynchronous API be limited to setCookie()? David
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:52 PM, David Flanagan wrote:
> Boris Zbarsky wrote:
>
>> On 2/24/10 1:04 PM, David Flanagan wrote:
>>
>>> If I've been following the thread correctly, the justification for an
>>> asynchronous API was that localStorage is a mess, or something like
>>> that. I'm not aware of what the issues are with localStorage
>>>
>>
>> In brief, the fact that if you have multiple threads or processes
>> rendering web pages from the same site, then they can race each other.
>>
>> could you justify an asynchronous cookie API more explicitly? This isn't
>>> a
>>> blocking I/O issue, is it? Surely browsers will have the relevant
>>> cookies already cached in memory, won't they?
>>>
>>
>> Yes, but cookies are not immutable.
>>
>> In simple use cases, a developer just wants the cookie value
>>>
>>
>> Only once? With a sync API this code:
>>
>> if (document.cookie == document.cookie) {
>>alert("pass");
>> } else {
>>alert("fail");
>> }
>>
>
> will sometimes alert "fail" depending on what other web pages are loading
>> at the same time and what their HTTP headers look like and what their
>> scripts are doing.
>>
>> -Boris
>>
>>
> [Changing the subject line back]
>
> Doesn't the HTML5 storage mutex fix this?
>
Please read my email from 30 minutes ago.
> With the storage mutex mechanism it is possible to create a safe (no way to
> observe volatility) synchronous version of getCookies(), isn't it?
Sure.
> The downside is that getCookies() might have to block while waiting for the
> mutex.
Exactly.
> But is that really a reason not to allow synchronous (blocking) access to
> cookies?
YES!
> Given that the storage mutex is already in the spec,
It's in the spec, but no one has implemented it or signaled any intention to
do so. We at Google have gone so far as to say that we will not implement
it. So, even though it's there, I'm not sure how much it means at this
point.
> doesn't it make sense to define a better synchronous API in addition to the
> new asynchronous API?
Please see all the LocalStorage discussions and then see if you still think
it's possible to do such a thing.
J
Re: [whatwg] HTML Cookie API
Boris Zbarsky wrote:
On 2/24/10 1:04 PM, David Flanagan wrote:
If I've been following the thread correctly, the justification for an
asynchronous API was that localStorage is a mess, or something like
that. I'm not aware of what the issues are with localStorage
In brief, the fact that if you have multiple threads or processes
rendering web pages from the same site, then they can race each other.
could you justify an asynchronous cookie API more explicitly? This
isn't a
blocking I/O issue, is it? Surely browsers will have the relevant
cookies already cached in memory, won't they?
Yes, but cookies are not immutable.
In simple use cases, a developer just wants the cookie value
Only once? With a sync API this code:
if (document.cookie == document.cookie) {
alert("pass");
} else {
alert("fail");
}
will sometimes alert "fail" depending on what other web pages are
loading at the same time and what their HTTP headers look like and what
their scripts are doing.
-Boris
[Changing the subject line back]
Doesn't the HTML5 storage mutex fix this?
With the storage mutex mechanism it is possible to create a safe (no way
to observe volatility) synchronous version of getCookies(), isn't it?
The downside is that getCookies() might have to block while waiting for
the mutex. But is that really a reason not to allow synchronous
(blocking) access to cookies? Given that the storage mutex is already
in the spec, doesn't it make sense to define a better synchronous API in
addition to the new asynchronous API?
David
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:23 PM, Peter Kasting wrote: > On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote: > >> I'm also less-than-thrilled with this being asynchronous, as I think the >> use cases for cookies are vastly differently than those for databases and >> web storage. The world is already parsing cookies synchronously right now, >> it doesn't seem like asynchronicity buys much benefit, it just introduces an >> additional level of indirection. > > > You haven't just spent several tortuous weeks trying to figure out how on > earth to correctly prompt for cookies in a multiprocess browser in a way > that doesn't break synchronicity requirements the way we have. > > Synchronous access to state didn't cause many issues when browsers were all > single-process, single-thread. That is increasingly not going to be the > world we live in. As Jonas mentioned, just look at localStorage (which, > contra your position, many developers have proposed using very much like > cookies) for recent history of why synchronous APIs are troublesome. > Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote: > I'm also less-than-thrilled with this being asynchronous, as I think the > use cases for cookies are vastly differently than those for databases and > web storage. The world is already parsing cookies synchronously right now, > it doesn't seem like asynchronicity buys much benefit, it just introduces an > additional level of indirection. You haven't just spent several tortuous weeks trying to figure out how on earth to correctly prompt for cookies in a multiprocess browser in a way that doesn't break synchronicity requirements the way we have. Synchronous access to state didn't cause many issues when browsers were all single-process, single-thread. That is increasingly not going to be the world we live in. As Jonas mentioned, just look at localStorage (which, contra your position, many developers have proposed using very much like cookies) for recent history of why synchronous APIs are troublesome. PK
Re: [whatwg] HTML Cookie API
For reference, reading document.cookie has measurable performance cost in
Chromium since the cookie jar lives in a process separate from the process
running JavaScript. We could have minimized this cost by caching the
cookies locally, but then there are cache coherency issues.
I think the cookie APIs should have been asynchronous from the start.
Whenever an API is backed by I/O, asynchronous should be the rule.
-Darin
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is
> why I wrote the YUI Cookie utility way back when). The thing that seems to
> be missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using
> your API, getting the value of a single cookie with a known name becomes:
>
>document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
>});
>
> That seems like a lot of work just to retrieve a single cookie value.
>
> I'm also less-than-thrilled with this being asynchronous, as I think the
> use cases for cookies are vastly differently than those for databases and
> web storage. The world is already parsing cookies synchronously right now,
> it doesn't seem like asynchronicity buys much benefit, it just introduces an
> additional level of indirection.
>
> -Nicholas
>
> __
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
>
> -Original Message-
> From: whatwg-boun...@lists.whatwg.org [mailto:
> whatwg-boun...@lists.whatwg.org] On Behalf Of Adam Barth
> Sent: Wednesday, February 24, 2010 8:47 AM
> To: Darin Fisher
> Cc: whatwg
> Subject: Re: [whatwg] HTML Cookie API
>
> Done.
>
> On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote:
> > An explicit deleteCookie method might also be nice.
> > -Darin
> >
> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> >>
> >> The document.cookie API is kind of terrible. Web developers shouldn't
> >> have to parse a cookie-string or prepare a properly formated
> >> set-cookie-string. Here's a proposal for an HTML cookie API that
> >> isn't as terrible:
> >>
> >>
> >>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
> >>
> >> I'd like to propose we include this API in a future version of HTML.
> >> As always, feedback welcome.
> >>
> >> Adam
> >
> >
>
Re: [whatwg] HTML Cookie API
I like the idea of creating an easier way to deal with cookies (which is why I
wrote the YUI Cookie utility way back when). The thing that seems to be missing
in your proposed API is what I consider to be the most common use case:
retrieving the value of a single cookie. There's not many times when I need to
get every single cookie that's available on the page, but there are plenty of
times when I want to check the value of a single cookie. Using your API,
getting the value of a single cookie with a known name becomes:
document.getCookies(function(cookies) {
for (var i=0; i < cookies.length; ++i){
if(cookies[i].name == "my_cookie_name"){
doSomething(cookies[i]);
}
}
});
That seems like a lot of work just to retrieve a single cookie value.
I'm also less-than-thrilled with this being asynchronous, as I think the use
cases for cookies are vastly differently than those for databases and web
storage. The world is already parsing cookies synchronously right now, it
doesn't seem like asynchronicity buys much benefit, it just introduces an
additional level of indirection.
-Nicholas
__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Adam Barth
Sent: Wednesday, February 24, 2010 8:47 AM
To: Darin Fisher
Cc: whatwg
Subject: Re: [whatwg] HTML Cookie API
Done.
On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote:
> An explicit deleteCookie method might also be nice.
> -Darin
>
> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
>>
>> The document.cookie API is kind of terrible. Web developers shouldn't
>> have to parse a cookie-string or prepare a properly formated
>> set-cookie-string. Here's a proposal for an HTML cookie API that
>> isn't as terrible:
>>
>>
>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>>
>> I'd like to propose we include this API in a future version of HTML.
>> As always, feedback welcome.
>>
>> Adam
>
>
Re: [whatwg] whatwg Digest, Vol 71, Issue 72
On 2/24/10 1:04 PM, David Flanagan wrote:
If I've been following the thread correctly, the justification for an
asynchronous API was that localStorage is a mess, or something like
that. I'm not aware of what the issues are with localStorage
In brief, the fact that if you have multiple threads or processes
rendering web pages from the same site, then they can race each other.
could you justify an asynchronous cookie API more explicitly? This isn't a
blocking I/O issue, is it? Surely browsers will have the relevant
cookies already cached in memory, won't they?
Yes, but cookies are not immutable.
In simple use cases, a developer just wants the cookie value
Only once? With a sync API this code:
if (document.cookie == document.cookie) {
alert("pass");
} else {
alert("fail");
}
will sometimes alert "fail" depending on what other web pages are
loading at the same time and what their HTTP headers look like and what
their scripts are doing.
-Boris
Re: [whatwg] whatwg Digest, Vol 71, Issue 72
Adam Barth wrote: We don't want to use the array syntax because we want the API to be asynchronous. Adam If I've been following the thread correctly, the justification for an asynchronous API was that localStorage is a mess, or something like that. I'm not aware of what the issues are with localStorage: could you justify an asynchronous cookie API more explicitly? This isn't a blocking I/O issue, is it? Surely browsers will have the relevant cookies already cached in memory, won't they? In simple use cases, a developer just wants the cookie value, and having to break an algorithm up into two functions because of an asynchronous API is a burden. There are lots of ways to wrap easy-to-use synchronous APIs around document.cookie. Do you think that developers will really transition to a slightly inconvenient async API when they could grab an off-the-shelf cookie library with an easier to use synchronous API? I guess I'm asking whether there is some fundamental reason why developers should be encouraged to abandon synchronous cookies. And if not, can we provide a nice synchronous API at the same time as a nice async API? How about getCookies() is synchronous when called with no arguments, but is async when passed a callback? David
Re: [whatwg] HTML Cookie API
Done. On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote: > An explicit deleteCookie method might also be nice. > -Darin > > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. >> >> Adam > >
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 12:12 AM, Anne van Kesteren wrote: > On Wed, 24 Feb 2010 05:56:31 +0100, Adam Barth wrote: >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. > > On http-state you argue that we should replace the cookie protocol with > something else. Why would we want a better API for cookies then? We're going to be stuck with cookies for a long time. We might as well make the APIs for interacting with them not terrible. Independent of that, I think we should warn people who aren't yet stuck with cookies to avoid them. However, the prevailing opinion in that working group appears to be to remove that piece of advice. Adam
Re: [whatwg] whatwg Digest, Vol 71, Issue 72
On Wed, Feb 24, 2010 at 3:55 AM, Anthony wrote:
> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
>> The document.cookie API is kind of terrible. Web developers shouldn't
>> have to parse a cookie-string or prepare a properly formated
>> set-cookie-string. Here's a proposal for an HTML cookie API that
>> isn't as terrible:
>>
>>
>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>>
>> I'd like to propose we include this API in a future version of HTML.
>> As always, feedback welcome.
>
> Sounds good, just a little suggestion:
> Maybe something like document.cookies.push({name: "a", value: "b"}) and/or
> document.cookies["a"]="b". Something similar to HTMLElement.style?
What's the advantage of putting the methods on a sub object of
document? That just seems like additional complexity. We don't want
to use the array syntax because we want the API to be asynchronous.
Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 10:22 PM, Darin Fisher wrote:
> On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth wrote:
>> On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote:
>> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
>> >> The document.cookie API is kind of terrible. Web developers shouldn't
>> >> have to parse a cookie-string or prepare a properly formated
>> >> set-cookie-string. Here's a proposal for an HTML cookie API that
>> >> isn't as terrible:
>> >>
>> >>
>> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>> >>
>> >> I'd like to propose we include this API in a future version of HTML.
>> >> As always, feedback welcome.
>
> I have frequently seen code like this:
>
> document.cookie = "foo=1";
> if (document.cookie.indexOf("foo") == -1) return;
> document.cookie = "bar=2";
> if (document.cookie.indexOf("bar") == -1) return;
>
> I presume it is not uncommon for web authors to want to know if the cookies
> were set. Maybe there should be an optional error callback on
> document.setCookie?
Done.
Adam
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Wed, 24 Feb 2010 16:45:44 +0100, Andrew Grieve wrote: How would you do #2 efficiently? If you used toDataUr*l*(), then you have to encode a png on one side and then decode the png on the main thread. I think we might want to add some sort of API for blitting directly from an offscreen canvas to an onscreen one. Perhaps via a canvas ID. postMessage() supports ImageData so you could use that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Offscreen canvas (or canvas for web workers).
Regarding the three steps of offscreen rendering: 1. Draw stuff 2. Ship pixels to main thread 3. Draw them on the screen. How would you do #2 efficiently? If you used toDataUr*l*(), then you have to encode a png on one side and then decode the png on the main thread. I think we might want to add some sort of API for blitting directly from an offscreen canvas to an onscreen one. Perhaps via a canvas ID. Andrew On Wed, Feb 24, 2010 at 6:12 AM, Maciej Stachowiak wrote: > > On Feb 24, 2010, at 1:35 AM, Jonas Sicking wrote: > > On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak >> wrote: >> >>> >>> On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: >>> >>> On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: >>> >>> On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak >>> wrote: >>> >>> - Raytracing a complex scene at high resolution. >>> >>> - Drawing a highly zoomed in high resolution portion of the Mandelbrot >>> set. >>> >>> To be fair though, you could compute the pixels for those with just math, >>> >>> there is no need to have a graphics context type abstraction. >>> >>> http://people.mozilla.com/~sicking/webgl/ray.html >>> >>> I did not think it was possible to write a proper raytracer for arbitrary >>> content all as a shader program, but I do not know enough about 3D >>> graphics >>> to know if that demo is correct or if that is possible in general. Point >>> conceded though. >>> >> >> The big thing that GLSL is lacking is a stack, making it impossible to >> recurse properly. This isn't a huge problem to work around, though can >> result in ugly code. Especially if you want to support transparent >> objects, in which case you'll essentially have to unroll recursion >> manually by copying code. >> >> This of course makes it impossible to recurse to arbitrary levels, >> though that is something you generally don't want to do anyway in a >> ray tracer since it costs a lot of CPU (or in this case GPU) cycles >> for very little visual gain. >> >> http://people.mozilla.com/~sicking/webgl/juliaanim.html >>> http://people.mozilla.com/~sicking/webgl/mandjulia.html >>> >>> Neither of examples you posted seems to have the ability to zoom in, so I >>> don't think they show anything about doing this to extremely high >>> accuracy. >>> But I see your point that much of this particular computation can be done >>> on >>> the GPU, up to probably quite high limits. Replace this example with your >>> choice of non-data-parallel computation. >>> >>> Following the links, this demo does do zoom, but it will go all jaggy >>> past a >>> certain zoom level, presumably due to limitations of GLSL. >>> http://learningwebgl.com/lessons/example01/? >>> >> >> Indeed. Zooming is no problem at all and doesn't require any heavier >> math than what is done in my demo. >> > > Zooming does require more iterations to get an accurate edge, and WebGL has > to limit your loop cycles at some point to prevent locking up the GPU. But > of course once you are at that level it would be pretty darn slow on a CPU. > I have seen mandelbrot demos that allow essentially arbitrary zoom (or at > least, the limit would be the size of your RAM, not the size of a float). > > > I experimented with allowing the >> animations to be stopped at arbitrary points and then allowing >> zooming. However it required more UI work than I was interested in >> doing at the time. >> >> The reason the demo goes jaggy after a while is due to limitations in >> IEEE 754 floats. >> > > On the CPU you could go past that if you cared to by coding your own high > precision math. But it would be quite slow. > > > >> But I should clarify that my point wasn't that WebGL makes >> off-main-thread graphics processing unneeded. I just thought it was >> funny that the two examples you brought up were exactly the things >> that I had experimented with. Although I wouldn't be surprised if a >> lot of the image processing effects that people want to do can be >> written as shader programs. Would definitely be interesting to know if >> WebGL could be supported on workers. >> > > I'm very much interested in the possibility of WebGL on Workers, which is > why I suggested, when reviewing early drafts of this proposal, that the > object should be an OffscreenCanvas rather than a special Worker-only > version of a 2d context (with implied built-in buffer). This makes it > possible to extend it to include WebGL. > > Regards, > Maciej > >
Re: [whatwg] whatwg Digest, Vol 71, Issue 72
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> The document.cookie API is kind of terrible. Web developers shouldn't
> have to parse a cookie-string or prepare a properly formated
> set-cookie-string. Here's a proposal for an HTML cookie API that
> isn't as terrible:
>
>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>
> I'd like to propose we include this API in a future version of HTML.
> As always, feedback welcome.
>
> Adam
>
Sounds good, just a little suggestion:
Maybe something like document.cookies.push({name: "a", value: "b"}) and/or
document.cookies["a"]="b". Something similar to HTMLElement.style?
Anthony
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Feb 24, 2010, at 1:35 AM, Jonas Sicking wrote: On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak wrote: On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. http://people.mozilla.com/~sicking/webgl/ray.html I did not think it was possible to write a proper raytracer for arbitrary content all as a shader program, but I do not know enough about 3D graphics to know if that demo is correct or if that is possible in general. Point conceded though. The big thing that GLSL is lacking is a stack, making it impossible to recurse properly. This isn't a huge problem to work around, though can result in ugly code. Especially if you want to support transparent objects, in which case you'll essentially have to unroll recursion manually by copying code. This of course makes it impossible to recurse to arbitrary levels, though that is something you generally don't want to do anyway in a ray tracer since it costs a lot of CPU (or in this case GPU) cycles for very little visual gain. http://people.mozilla.com/~sicking/webgl/juliaanim.html http://people.mozilla.com/~sicking/webgl/mandjulia.html Neither of examples you posted seems to have the ability to zoom in, so I don't think they show anything about doing this to extremely high accuracy. But I see your point that much of this particular computation can be done on the GPU, up to probably quite high limits. Replace this example with your choice of non-data-parallel computation. Following the links, this demo does do zoom, but it will go all jaggy past a certain zoom level, presumably due to limitations of GLSL. http://learningwebgl.com/lessons/example01/? Indeed. Zooming is no problem at all and doesn't require any heavier math than what is done in my demo. Zooming does require more iterations to get an accurate edge, and WebGL has to limit your loop cycles at some point to prevent locking up the GPU. But of course once you are at that level it would be pretty darn slow on a CPU. I have seen mandelbrot demos that allow essentially arbitrary zoom (or at least, the limit would be the size of your RAM, not the size of a float). I experimented with allowing the animations to be stopped at arbitrary points and then allowing zooming. However it required more UI work than I was interested in doing at the time. The reason the demo goes jaggy after a while is due to limitations in IEEE 754 floats. On the CPU you could go past that if you cared to by coding your own high precision math. But it would be quite slow. But I should clarify that my point wasn't that WebGL makes off-main-thread graphics processing unneeded. I just thought it was funny that the two examples you brought up were exactly the things that I had experimented with. Although I wouldn't be surprised if a lot of the image processing effects that people want to do can be written as shader programs. Would definitely be interesting to know if WebGL could be supported on workers. I'm very much interested in the possibility of WebGL on Workers, which is why I suggested, when reviewing early drafts of this proposal, that the object should be an OffscreenCanvas rather than a special Worker- only version of a 2d context (with implied built-in buffer). This makes it possible to extend it to include WebGL. Regards, Maciej
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Wed, Feb 24, 2010 at 1:35 AM, Jonas Sicking wrote: > On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak wrote: >> >> On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: >> >> On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: >> >> On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote: >> >> - Raytracing a complex scene at high resolution. >> >> - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. >> >> To be fair though, you could compute the pixels for those with just math, >> >> there is no need to have a graphics context type abstraction. >> >> http://people.mozilla.com/~sicking/webgl/ray.html >> >> I did not think it was possible to write a proper raytracer for arbitrary >> content all as a shader program, but I do not know enough about 3D graphics >> to know if that demo is correct or if that is possible in general. Point >> conceded though. > > The big thing that GLSL is lacking is a stack, making it impossible to > recurse properly. This isn't a huge problem to work around, though can > result in ugly code. Especially if you want to support transparent > objects, in which case you'll essentially have to unroll recursion > manually by copying code. > > This of course makes it impossible to recurse to arbitrary levels, > though that is something you generally don't want to do anyway in a > ray tracer since it costs a lot of CPU (or in this case GPU) cycles > for very little visual gain. Oh, but the math is definitely correct, so GLSL ray tracing is quite possible. / Jonas
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak wrote: > > On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: > > On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: > > On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote: > > - Raytracing a complex scene at high resolution. > > - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. > > To be fair though, you could compute the pixels for those with just math, > > there is no need to have a graphics context type abstraction. > > http://people.mozilla.com/~sicking/webgl/ray.html > > I did not think it was possible to write a proper raytracer for arbitrary > content all as a shader program, but I do not know enough about 3D graphics > to know if that demo is correct or if that is possible in general. Point > conceded though. The big thing that GLSL is lacking is a stack, making it impossible to recurse properly. This isn't a huge problem to work around, though can result in ugly code. Especially if you want to support transparent objects, in which case you'll essentially have to unroll recursion manually by copying code. This of course makes it impossible to recurse to arbitrary levels, though that is something you generally don't want to do anyway in a ray tracer since it costs a lot of CPU (or in this case GPU) cycles for very little visual gain. > http://people.mozilla.com/~sicking/webgl/juliaanim.html > http://people.mozilla.com/~sicking/webgl/mandjulia.html > > Neither of examples you posted seems to have the ability to zoom in, so I > don't think they show anything about doing this to extremely high accuracy. > But I see your point that much of this particular computation can be done on > the GPU, up to probably quite high limits. Replace this example with your > choice of non-data-parallel computation. > > Following the links, this demo does do zoom, but it will go all jaggy past a > certain zoom level, presumably due to limitations of GLSL. > http://learningwebgl.com/lessons/example01/? Indeed. Zooming is no problem at all and doesn't require any heavier math than what is done in my demo. I experimented with allowing the animations to be stopped at arbitrary points and then allowing zooming. However it required more UI work than I was interested in doing at the time. The reason the demo goes jaggy after a while is due to limitations in IEEE 754 floats. But I should clarify that my point wasn't that WebGL makes off-main-thread graphics processing unneeded. I just thought it was funny that the two examples you brought up were exactly the things that I had experimented with. Although I wouldn't be surprised if a lot of the image processing effects that people want to do can be written as shader programs. Would definitely be interesting to know if WebGL could be supported on workers. / Jonas
Re: [whatwg] HTML Cookie API
An explicit deleteCookie method might also be nice. -Darin On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: > The document.cookie API is kind of terrible. Web developers shouldn't > have to parse a cookie-string or prepare a properly formated > set-cookie-string. Here's a proposal for an HTML cookie API that > isn't as terrible: > > > https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en > > I'd like to propose we include this API in a future version of HTML. > As always, feedback welcome. > > Adam >
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. http://people.mozilla.com/~sicking/webgl/ray.html I did not think it was possible to write a proper raytracer for arbitrary content all as a shader program, but I do not know enough about 3D graphics to know if that demo is correct or if that is possible in general. Point conceded though. http://people.mozilla.com/~sicking/webgl/juliaanim.html http://people.mozilla.com/~sicking/webgl/mandjulia.html Neither of examples you posted seems to have the ability to zoom in, so I don't think they show anything about doing this to extremely high accuracy. But I see your point that much of this particular computation can be done on the GPU, up to probably quite high limits. Replace this example with your choice of non-data-parallel computation. Following the links, this demo does do zoom, but it will go all jaggy past a certain zoom level, presumably due to limitations of GLSL. http://learningwebgl.com/lessons/example01/? Regards, Maciej
Re: [whatwg] HTML Cookie API
On Wed, 24 Feb 2010 05:56:31 +0100, Adam Barth wrote: The document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. On http-state you argue that we should replace the cookie protocol with something else. Why would we want a better API for cookies then? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. http://people.mozilla.com/~sicking/webgl/ray.html I did not think it was possible to write a proper raytracer for arbitrary content all as a shader program, but I do not know enough about 3D graphics to know if that demo is correct or if that is possible in general. Point conceded though. http://people.mozilla.com/~sicking/webgl/juliaanim.html http://people.mozilla.com/~sicking/webgl/mandjulia.html Neither of examples you posted seems to have the ability to zoom in, so I don't think they show anything about doing this to extremely high accuracy. But I see your point that much of this particular computation can be done on the GPU, up to probably quite high limits. Replace this example with your choice of non-data-parallel computation. Very sexy demos, by the way. Regards, Maciej
