Re: [whatwg] Persistent SharedWorkers

[Matthew Paul Thomas]

Drew Wilson wrote on 06/03/09 23:39:
>...
> - Worker UI:
> From the worker standpoint, the main difference between a
> PersistentWorker and other types of workers is that the normal way of
> interacting with the user (via an open browser window) is not
> available, since there may be no windows open to the parent domain. We
> have yet to enumerate through all of the use cases, but our initial
> brainstorming came up with a few possible types of desired
> interactions:
> 
> 1) Display an icon in the OS status bar. This would be an unobtrusive
> way for a given domain to display things like "you have new mail" or
> even errors like "unable to contact server".

Speaking for Ubuntu, we are making active efforts to reduce the number
of elements in the notification area (aka "system tray"), with the items
remaining there being system-wide things rather than
application-specific things. We would not be willing to let Web
applications insert icons there. (Similarly, recent versions of
Windows have been more aggressive about hiding notification area icons
by default.)

>  If supplied with an
> onclick handler, this could also be the footprint for further types of
> user interaction:

We also plan to make panel elements behave consistently as menus, rather
than some being menus and others being buttons, so an onclick handler
alone wouldn't work so well even if we allowed the icon.

>...
> 3) Toast (http://en.wikipedia.org/wiki/Toast_(computing)
> ) - behavior is
> similar to the showNotification() API that was previously in HTML5.
>...
> showNotification(url) - displays the HTML at the passed URL to the
> user via a toast popup. user agents may put restrictions on the size
> of the resulting window. The original HTML5 showNotification() API was much
> more limited (a few lines of unstyled text, an icon, and an onclick
> handler) - Dmitry Titov makes the case for full-HTML notifications
> here: http://docs.google.com/Doc?id=dhg4xn62_28f8cwvzf8 - I have some
> concerns about phishing (since there's not necessarily any indication
> about the source of a given notification), so that may impact our
> implementation.
>...

Ubuntu 9.04 will feature initial work to ensure that notifications
either pop up above other windows, or are interactive, but not both.
(This is to avoid accidental clicks, and to allow interacting with
whatever is under a popup notification without having to close it
first.) Allowing arbitrary HTML in popup notifications would be
basically incompatible with that. We would be happy to let Web pages
show popup notifications using an icon and unstyled text, but not an
onclick handler.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg]

[Charles McCathieNevile]

(I thnk this is a permathread for the moment, so posting it to HTML as  
well for reference. Is there an issue raised for this, or whatever the  
method /du jour/ for identifying questions to be dealt with is?)


On Tue, 10 Mar 2009 01:36:33 +0100, Toby A Inkster  
 wrote:


It does seem to me to be a little foolhardy for HTML5 to be defining its  
own format for representing dates and times. ISO 8601 is already widely  
understood and implemented. Out of the box it is capable of representing  
any instant[1] between 1 BC and  AD, including leap seconds and  
any other edge case you choose to think about. Why reinvent the wheel?


In the same way that the W3C Date Time Format note did, it makes sense to  
profile ISO 8601 (which is monstrously big as well, and allows lots of  
different stuff). Indeed, referring to that (it is probably the most  
common format used in metadata communities, who are likely to be  
interested in using the element in the first place) would be a step  
forward.


That format has some serious limitations for heavy metadata users. In  
particular for those who are producing information about historical  
objects, from British Parliamentary records to histories of pre-communist  
Russia or China to museum collections, the fact that it doesn't handle  
Julian dates is a big problem - albeit one that could be solved relatively  
simply in a couple of different ways.


The other issue is the one of precision - while you can name a single  
year, which will deal with a lot of use cases there are a lot left out  
because the precision required is a period. Ranges are included in 8601,  
and making a range syntax that handled almost all the relevant use cases  
is pretty straightforward.


Enabling these more complex use cases would resolve a lot of people's  
uneasiness over the limited utility of the current design. It would also  
make it easier to explain to communities who publish or hold large amounts  
of metadata how HTML 5 gives them a clear benefit.


An alternative approach of course would be to enable RDFa, since using RDF  
it is already simple to deal with these use cases, and the people who have  
them very often ahve their data in an RDF-compatible form already.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg]

[Toby A Inkster]

It does seem to me to be a little foolhardy for HTML5 to be defining  
its own format for representing dates and times. ISO 8601 is already  
widely understood and implemented. Out of the box it is capable of  
representing any instant[1] between 1 BC and  AD, including  
leap seconds and any other edge case you choose to think about. Why  
reinvent the wheel?



1. Well, fractional seconds only to a finite number of decimal  
places, but let's not split hairs.


--
Toby A Inkster

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 5:11 PM, Drew Wilson  wrote:
>>
>>
>> > and most important
>> > 3) why it did actually happen in my code? (using an async XHR)
>>
>> Not sure what you are saying here. Do you have example code.
>
> I think what he's talking about the issue described at
> http://www.nerdgod.com/ie7test2.html.
>
> I was CC'd on an email thread about this last year - IE can sometimes call
> xhr callbacks at inappropriate times (like when in the middle of a JS
> function call). Summarizing the thread, it seems that invoking certain JS
> functions in IE (like alert()) can cause IE to re-enter the message loop and
> start processing messages which can cause things like XHR request callbacks
> to be invoked.
>
> I'm pretty sure this is better classified as a bug in IE rather than as
> expected JS language behavior, though.

Same thing can happen in Firefox 3. We also consider it a bug though
and would like to get it fixed. It is non-trivial to fix though, but
Firefox 3.1 has some improvements.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

>
>
>
> > and most important
> > 3) why it did actually happen in my code? (using an async XHR)
>
> Not sure what you are saying here. Do you have example code.
>

I think what he's talking about the issue described at
http://www.nerdgod.com/ie7test2.html.

I was CC'd on an email thread about this last year - IE can sometimes call
xhr callbacks at inappropriate times (like when in the middle of a JS
function call). Summarizing the thread, it seems that invoking certain JS
functions in IE (like alert()) can cause IE to re-enter the message loop and
start processing messages which can cause things like XHR request callbacks
to be invoked.

I'm pretty sure this is better classified as a bug in IE rather than as
expected JS language behavior, though.

-atw

Re: [whatwg] URL encoding for XHR and Workers.

[Jonas Sicking]

On Fri, Mar 6, 2009 at 4:51 PM, Dmitry Titov  wrote:
> Hi,
> I have a couple of questions about Web Workers and text encoding of URLs.
> Usually, 'server' and 'path' portions of URLs are always sent in UTRF-8, the
> 'query' portion may be sent encoded if it contains non-ascii characters. I'm
> looking at what should be an encoding used for this.
> Lets say we have the Page that creates a Worker which uses includeScripts to
> load the NestedScript.
> Lets say the Page has some text encoding (from http header, meta tag or
> otherwise). For example, in latest FF nightly (Minefield) the following
> behaviors can be observed:
> - XmlHttpRequest created on the Page would send its URL to server encoded
> using UTF8, irrespective to the encoding of the Page. However, a
> XmlHttpRequest created in the Worker would send the URL encoded using Page's
> encoding. It seems that either XHR on the Page should also use Page's
> encoding, or XHR in the Worker should use UTF-8. Bug?

Sounds like it. Would be great if you could file a bug. That is why we
have beta releases :)

> - When a script of the Worker is decoded, the encoding of the Page is used,
> unless Worker's script comes with http header overriding the ecncoding. That
> sounds right. However, if the Worker in turn creates a nested Worker, uses
> an XHR or importScripts(url), the URL encoding defaults back to the Page's,
> even if there was overriding http header. It might be ok but seems a bit
> illogical - the nested worker or imported scripts are 'sub resources', their
> relative url is resolved against the Worker's base url, so it feels that
> their default encoding should be inherited from Worker. Is it a bug?

I suspect so yes.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 11:46 AM, Giovanni Campagna
 wrote:
> 2009/3/9 Jonas Sicking :
>> On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
>>  wrote:
>>> 2009/3/9 Jonas Sicking :
 On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
> This can be even worse: how would you syncronize the code in the
> callback with code right after the call? You don't have any of
> semaphores or mutexes in ES and I don't expect them to be added soon.

 I'm not sure I understand the problem you are describing. Could you
 show an example using the APIs that exist in the spec today and with
 an async cookie API added?
>>>
>>> var x = 7;
>>> function callback(cookies) {
>>> x = 5;
>>> }
>>> getAllCookies(callback);
>>> alert(x == 7);
>>
>> True. The callback can't happen in the middle of executing code.
>> Javascript uses a run-to-completion model.
>
> 1) what does that mean?

Sorry, i was unclear. The above program will always alert 'true'.

This happens because the callback doesn't fire until the current run
of javascript is finished executing. I.e. until the current event is
done executing.

> the code is executed in certain specific moments (when the thread is
> waiting on a native call)
> // doesn't seem very reliable, unless we specify what "native call" means

So something like this yes. We do need to specify what "native call"
means yes. The HTML5 spec does this as it is defining the runtime
environment for script execution.

> 2) where is that specified?
> I don't remember if the original Ecma262 has something about asyncronous calls

This area is in general woefully under specified by W3C. The HTML5
spec is the first attempt at specifying this.

> and most important
> 3) why it did actually happen in my code? (using an async XHR)

Not sure what you are saying here. Do you have example code.

/ Jonas

Re: [whatwg]

[Charles McCathieNevile]

On Mon, 09 Mar 2009 21:17:01 +0100, Tom Duhamel   
wrote:




Precise Date/Time

My understanding is that the current protocol will only accept this  
format for a valid precise date:

2009-03-09
And this format for a valid precise time:
15:10 or 15:10:19

My opinion is that all the following dates are precise:
2009
2009-03
2009-03-09


I agree. These are also acceptable with ISO-8601 (although to be honest  
that spec accepts so many things it isn't always a good reference) and I  
think they are indeed useful things to be able to say about the future.



Gregorian Calendar

There have been requests that the  element accepts dates expressed  
in other calendars than Gregorian. This is not doable, although I do  
understand those who mentioned this, mostly about the Julian calendar.


Julian for instance cannot give a precise date (we are not considering  
the fact that it was not precise enough) because it was based on some

events in history, often the arrival of a new leader. For example,
when Bush was elected in Nov 2000, we would have considered that year
to be the new year 1. Thus Bush was elected in November 1, re-elected
in November 5. Then Obama was elected in November 9 of the Bush era,
which was also Novemember 1 of Obama era.


This is not correct. (I am, as it happens, an historian who works at  
something else :) ). The Julian calendar only came into being in about  
45BCE, and leap years were a bit odd until about 40 years later. For Roman  
calendars before the Julian calendar there is pretty good evidence,  
although they were named for the consuls elected that year. I.e. years  
were generally known by a pair of names rather than a number, but you can  
go back a long way with those names.


Wikipedia is often mentioned as a use-case, but based on my own  
experience (I am not an historian or anything, so my use of

Wikipedia for historical events is sporadic) they most usually
convert Julian dates to the Gregorian calendar. Julius Caesar
died in 14 BC, not 52 of the Julius era on the Julian calendar
(or whatever date it would convert to).


Nope, you are confusing your calendars here. The Gregorian and Julian  
calendars look the same, but 3 times every 400 years the Gregorian  
calendar skips a leap year that would have occurred in the Julian one. So  
Wikipedia dates are generally (but not always) Julian.


What does happen is that Roman years were still named for consuls - the  
convention of using the supposed birth of Jesus as the year 1 came a few  
centuries later. So the "50 BC" bit in Asterix would have been called "the  
year of the consuls L. Aemilius Lepidus Paullus C. Claudius Marcellus" at  
the time - and the year 100 AD would have been called something similar.  
The reason why we count back so many years is because we have very good  
records that make it easy to turn the named years into numbers (for people  
who didn't go to a Roman school and get beaten until they could recite the  
names of consuls for a few centuries), and can easily date lots of events  
(but not the birth of Jesus, which probably took place around 4-6 BC :) ).


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg]

[Smylers]

Tom Duhamel writes:

> My opinion is that all the following dates are precise:
> 2009
> 2009-03
> 2009-03-09
> 
> The later is more precise, but the three are all precise in my
> opinion. 

Being precise means having a small granularity.  Obviously that's
subjective, but in many cases granularity of a year would be deemed
quite large.

> There are numerous reason to use dates which are not very precise, but are
> still precise nevertheless. I'm going to release the new version of my
> current project in April but I cannot tell
> as of now the exact day of the release.

Indeed, that's a reason to use an imprecise date in that paragraph of
text.  But it isn't apparently why that date needs to be marked up as
such; what consumers of the above HTML would do something useful with
it?

> On the other hand, those are NOT precise dates:
> Last year
> About a month ago

That's considerably more precise than "2009", in that it bounds a much
smaller period of time than a whole year.  But I don't see how any of
this is revelant; the date support that HTML 5 needs is that which is
generally useful, not something that happens to meet either your or my
definitions of particular terms.

> From my understanding of the current draft, the earlier date that can
> be used is 1970-01-01.

I think you're mistaken.  The  definition requires a valid date or
time:

  
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element

The date component of which must be a valid date string:

  
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-date-or-time-string
  
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-date-string

Which must start with a valid month string:

  
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-month-string

Which has the constraint year > 0.

Smylers

Re: [whatwg] Historic dates in HTML5

[Lachlan Hunt]

Bruce Lawson quoted Andy Mabbat:

Andy Mabbett has already listed use cases
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639.html
...
They can be mapped visually on a "SIMILE"

  

or similar time-line.


It's not clear how such a timeline would make use of the time element 
and I couldn't find any use of microformats on that page.  Could you 
please elaborate on the relevance of that page in regards to this issue?


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[whatwg]

[Tom Duhamel]

There have been a lot of discussion around the  element lately, and I
followed most of it since I'm pretty interested in this element, and frankly
I believe it will be very useful in the future. However, I too have opinions
around this. I do agree with some argument presented before, and disagree
with others. This post is not meant to be very long, I just wanted to state
a bit about my opinion, although I don't consider myself knowledgeable
enough to discuss the entire set of issues.

Precise Date/Time

My understanding is that the current protocol will only accept this format
for a valid precise date:
2009-03-09
And this format for a valid precise time:
15:10 or 15:10:19

My opinion is that all the following dates are precise:
2009
2009-03
2009-03-09

There are numerous reason to use dates which are not very precise, but are
still precise nevertheless. I'm going to release the new version of my
current project in April but I cannot tell
as of now the exact day of the release.

The later is more precise, but the three are all precise in my opinion. On
the other hand, those are NOT precise dates:
Last year
About a month ago
Last summer
Somewhere during the summer of 2010

The same would apply to times. "This morning", "I'll be there in an hour"
are not precise.


Gregorian Calendar

There have been requests that the  element accepts dates expressed in
other calendars than Gregorian. This is not doable, although I do understand
those who mentioned this, mostly about the Julian calendar.

Julian for instance cannot give a precise date (we are not considering the
fact that it was not precise enough) because it was based on some events in
history, often the arrival of a new leader. For example, when Bush was
elected in Nov 2000, we would have considered that year to be the new year
1. Thus Bush was elected in November 1, re-elected in November 5. Then Obama
was elected in November 9 of the Bush era, which was also Novemember 1 of
Obama era.

Wikipedia is often mentioned as a use-case, but based on my own experience
(I am not an historian or anything, so my use of Wikipedia for historical
events is sporadic) they most usually convert Julian dates to the Gregorian
calendar. Julius Caesar died in 14 BC, not 52 of the Julius era on the
Julian calendar (or whatever date it would convert to).


Historic Dates

>From my understanding of the current draft, the earlier date that can be
used is 1970-01-01. The Unix epoch. Why that limit?

Gregorian calendar entered common use somewhere during the 15th century, I
believe. Dates in 16th, 17th, 18th, 19th and 20th centuries are very common.
Dates before the 15th centurie are less common, they are usually not precise
(just 14th century, for example, as the exact year cannot be determined),
but there are cases where the exact date is known. Julius Caesar is one
instance where a precise date is known (for both his birth and death) and
this is around 50 BC. I don't think there are many known precise date before
that. I would accept that dates before year 1 be not represented. I would
even accept that dates before 15th century be not representable since those
cannot be accurately represented (I'm not historian, I hope people more
knowleadgeable than me will point out the correct date for the event).
However I think 1970 is not that good, as for sure even recent historic
events cannot be pinpointed correctly.

If the protocol is to be kept as is, it should be made clear that the 
element is for current dates, not historic dates, as I would assume that
would be the reason for the choice of 1970 (which is actually a good choice
for simplicity of implementation). If this was not the intended use (that
is, it was also meant for historic dates) than the limit would really need
to be changed. In my opinion, 1 or 1400 are not a good limit if we are to
allow use for historic dates. I would allow all dates, including BC dates.

The upper limit does not seem to be mentioned. It should be, and it should
be at least , although no limit would be better (although I understand
it becomes more difficult to implement past  -- actually I think it's
already diffucult to implement up to ).

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

Following up on this. I created two pages, one that tests cookies in a loop,
and one that sets cookies in a loop, and ran them in separate windows in
Firefox 3, IE7, and Chrome.

Chrome and IE7 currently allow concurrent modification of document.cookies
(i.e. the test loop throws up an alert). Firefox does not.

My two pages are below - do you see any problems with my test? If not, I'd
like to propose that browsers do not currently impose any guarantees as to
the immutability of document.cookies, so there's no reason not to support
synchronous access to cookies from workers.

-atw





  Testing cookies: 0
  Start
  
var count = 1;
function cookieTest() {
  var a = document.cookie;
  for (var i = 0 ; i < 1 ; i++) {
var b = document.cookie;
if (a != b) {
  alert("a: " + a + "\nb:" + b);
}
  }
  setTimeout(cookieTest, 0);
  document.getElementById('log').innerHTML = count++;
};
  









  setCookies: 0
  Start
  
var count = 1;
function cookieSet() {
  for (var i = 0 ; i < 1 ; i++) {
document.cookie = ("cookieSetVal=" + i);
  }
  setTimeout(cookieSet, 0);
  document.getElementById('log').innerHTML = count++;
};
  




On Mon, Mar 9, 2009 at 11:38 AM, Drew Wilson  wrote:

>
>
> On Mon, Mar 9, 2009 at 10:23 AM, Jonas Sicking  wrote:
>
>>
>> The problem is that people are likely to write code like:
>>
>> if (self.getAllCookies() != "magic value") {
>>  a = self.getAllCookies();
>>  ...do stuff...
>> }
>>
>> at that point it's entirely possible for 'a' to have the value "magic
>> value" which is likely to cause the script to break.
>
>
> Here we are making assumptions about how people will use routines that
> don't actually exist yet. If you were to substitute "new Date().getTime()"
> for "self.getAllCookies()" in the code above, I think we'd all agree that
> the user expectation is faulty - is it not feasible to state that, just like
> Date().getTime(),. getAllCookies() returns a snapshot of a mutable value?
>
> I'm OK with making setCookie() asynchronous, because I think there may be a
> valid point that you don't want new worker code to suddenly break existing
> JS code that expects document.cookies to remain immutable across a single
> block of execution. But I don't see that argument extending to
> getAllCookies().
>
>
>>
>> Indeed. It does seem like you would be able to ask ;)
>>
>
> I'm looking into this now, actually :) - I'll let you know what I find out.
>
> -atw
>
>

Re: [whatwg] URL encoding for XHR and Workers.

[Dmitry Titov]

Update:Ian Hixie pointed to places in spec which specify very clearly that
all URLs in workers will be encoded in UTF-8 (including query part) before
sent over wire regardless of whether it is a new worker, importScripts or
XHR URL.

The "encoding of the script" is set to UTF-8 as prescribed by Workers spec,
section 2.5, step 3. This overrides the 'inherited' encoding from the parent
document and even http header for the worker's script. At the same time,
HTML5 spec, section 2.5.1 says URL that came from script has encoding of the
script.

So the FF beta behavior (encode URLs using the encoding of the top-level
document that created the first level worker) seems to be incorrect, I plan
to file a bug on it.

Dmitry


On Sat, Mar 7, 2009 at 9:39 AM, Anne van Kesteren  wrote:

> On Sat, 07 Mar 2009 00:51:51 +0100, Dmitry Titov 
> wrote:
>
>> - XmlHttpRequest created on the Page would send its URL to server encoded
>> using UTF8, irrespective to the encoding of the Page. However, a
>> XmlHttpRequest created in the Worker would send the URL encoded using
>> Page's encoding. It seems that either XHR on the Page should also use Page's
>> encoding, or XHR in the Worker should use UTF-8. Bug?
>>
>
> I don't see how Web Workers specification overrides UTF-8 here. Admittedly,
> XMLHttpRequest does need to be updated to be able to get base URLs not
> derived from Window/Document.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] Accessing cookies from workers

[Giovanni Campagna]

2009/3/9 Jonas Sicking :
> On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
>  wrote:
>> 2009/3/9 Jonas Sicking :
>>> On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
 This can be even worse: how would you syncronize the code in the
 callback with code right after the call? You don't have any of
 semaphores or mutexes in ES and I don't expect them to be added soon.
>>>
>>> I'm not sure I understand the problem you are describing. Could you
>>> show an example using the APIs that exist in the spec today and with
>>> an async cookie API added?
>>
>> var x = 7;
>> function callback(cookies) {
>> x = 5;
>> }
>> getAllCookies(callback);
>> alert(x == 7);
>
> True. The callback can't happen in the middle of executing code.
> Javascript uses a run-to-completion model.

1) what does that mean?
The code in the callback is executed before reaching code outside
// doesn't seem very asyncronous
-or-
the code is executed after everything outside is already gone
// doesn't seem very useful, because code outside needs the result of
the cookie dependent routine
-or-
the code is executed in certain specific moments (when the thread is
waiting on a native call)
// doesn't seem very reliable, unless we specify what "native call" means

2) where is that specified?
I don't remember if the original Ecma262 has something about asyncronous calls

and most important
3) why it did actually happen in my code? (using an async XHR)

> / Jonas
>

Giovanni

@Drew:
If you don't want that workers set cookies in the middle of a JS block
in another browsing context, you just need to add a mutex at the
beginning of JS threads (timeout / intervals and event handlers), then
lock on that mutex in the setCookie.
This would make the call syncronous without problems for the JS developer.

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

On Mon, Mar 9, 2009 at 10:23 AM, Jonas Sicking  wrote:

>
> The problem is that people are likely to write code like:
>
> if (self.getAllCookies() != "magic value") {
>  a = self.getAllCookies();
>  ...do stuff...
> }
>
> at that point it's entirely possible for 'a' to have the value "magic
> value" which is likely to cause the script to break.


Here we are making assumptions about how people will use routines that don't
actually exist yet. If you were to substitute "new Date().getTime()" for
"self.getAllCookies()" in the code above, I think we'd all agree that the
user expectation is faulty - is it not feasible to state that, just like
Date().getTime(),. getAllCookies() returns a snapshot of a mutable value?

I'm OK with making setCookie() asynchronous, because I think there may be a
valid point that you don't want new worker code to suddenly break existing
JS code that expects document.cookies to remain immutable across a single
block of execution. But I don't see that argument extending to
getAllCookies().


>
> Indeed. It does seem like you would be able to ask ;)
>

I'm looking into this now, actually :) - I'll let you know what I find out.

-atw

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 11:26 AM, Giovanni Campagna
 wrote:
> 2009/3/9 Jonas Sicking :
>> On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
>>> This can be even worse: how would you syncronize the code in the
>>> callback with code right after the call? You don't have any of
>>> semaphores or mutexes in ES and I don't expect them to be added soon.
>>
>> I'm not sure I understand the problem you are describing. Could you
>> show an example using the APIs that exist in the spec today and with
>> an async cookie API added?
>
> var x = 7;
> function callback(cookies) {
> x = 5;
> }
> getAllCookies(callback);
> alert(x == 7);

True. The callback can't happen in the middle of executing code.
Javascript uses a run-to-completion model.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Giovanni Campagna]

2009/3/9 Jonas Sicking :
> On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
>> This can be even worse: how would you syncronize the code in the
>> callback with code right after the call? You don't have any of
>> semaphores or mutexes in ES and I don't expect them to be added soon.
>
> I'm not sure I understand the problem you are describing. Could you
> show an example using the APIs that exist in the spec today and with
> an async cookie API added?

var x = 7;
function callback(cookies) {
x = 5;
}
getAllCookies(callback);
alert(x == 7);

True or false: who knows?
The example is rather trivial, but this issue can be very frustrating
once you start doing something useful inside the callback: since you
have neither arguments nor return values, the only way to propagate
the results from function to outside is using a global-scope object.
Btw, this problem forced me using syncronous XHR, so maybe the
introduction of a low-level threading / syncronization mechanism may
be appropriate. Something that the casual author would not usually
need, but some professional web developer will find extremely useful,
surely better than self-dispatching events.

> / Jonas
>

Giovanni

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 11:07 AM, Drew Wilson  wrote:
>>
>> No, this is a synchronous API which is not acceptible since it creates
>> a multithreaded environment for web developers. You need to use a
>> callback function.
>
> Hmmm, I must've misinterpreted your previous statement:
>
 It seems like it should fine to allow reading cookies in dedicated
 workers though.

No, you're not wrong. *I* was wrong when I wrote the above statement.

> I'm sure I'm being obtuse, but I don't understand what you are saying here.
>
> Let's imagine that I have a synchronous API - you are saying that this is
> bad, because when I do this:
>
> var cookies = self.getAllCookies();
> doSomethingWithCookies(cookies);

The problem is that people are likely to write code like:

if (self.getAllCookies() != "magic value") {
  a = self.getAllCookies();
  ...do stuff...
}

at that point it's entirely possible for 'a' to have the value "magic
value" which is likely to cause the script to break.

> So, let's assume instead that we allow passing a callback to
> getAllCookies():
>
> self.getAllCookies( function(cookies) { doSomethingWithCookies(cookies); })
>
> When doSomethingWithCookies() is invoked, whatever operation it is
> performing may fail, because the passed-in value of cookies may still be out
> of date.
>
> Making getAllCookies() asynchronous means that the trivial fail case:
>
> var a = getAllCookies();
> var b = getAllCookies();
> assert(a === b);
>
> ...can no longer fail because there's no return value. But fundamentally the
> underlying problem continues to exist - the cookies may have changed behind
> the scene, so whatever snapshot you have (either delivered synchronously or
> asynchronously) may be out-of-date. So making getAllCookies() asynchronous
> does not buy you anything, and additionally makes this API painful to use.

The only thing it prevents is for the javascript code to get inconsistent state.

I do agree that once you hit the wire using XHR or something else you
risk not having the state that you thought you would. I'm not sure
what to do about that problem.

> As an aside, I wonder how a multi-process browser like Chrome handles
> cookies even in the absence of workers - if I open two windows (separate
> processes) under the same domain and set cookies in both, it seems like
> there's an existing race condition.

Indeed. It does seem like you would be able to ask ;)

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
 wrote:
> 2009/3/9 Jonas Sicking :
>> On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson  wrote:
>>>
>>> On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking  wrote:

 However a much more interesting question is if sites would break if
 the above stopped being true. That is most definitely the case.
>>>
>>> Agreed - existing behavior trumps spec ambiguity. However, in this case I
>>> was assuming that breaking existing sites was not an issue since we're
>>> adding completely new functionality (accessing cookies from workers).
>>> Existing sites won't break unless they add worker code that modifies
>>> cookies, although perhaps that's a situation we need to avoid as well.
>>
>> I wouldn't expect new sites to be able to cope with this either. Even
>> if we put in the spec that the value can change at any time, it is
>> extremely unlikely that developers will deal with this appropriately.
>
> They cannot deal with that, given they don't have any syncronization
> mechanism outside the event system. To control the value of shared
> variables, you need a lock on that variable while you're using it.

Indeed, in a multithread environment we'd need that. However the goal
of workers is to use a shared-nothing message passing model where this
is not needed. Think of them as separate processes rather than
separate threads.

>> See my analogy earlier in this thread regarding how hard it is to
>> write multi-threaded code, even for expert C++ developers. It is
>> definitely not something I would expect copy-n-paste web developers to
>> get right.
>
> If you don't understand the logics of multithreading, you should not
> use workers (that are just ecmascript threads with a message queue),
> IMHO.

Why? In the drafts that exist today (with the exception of
localStorage), why is this needed?

 This is a very interesting suggestion. If we add a cookie access API
 then this would seem like a reasonable thing to require from that API.

>>>
>>> OK, to summarize, the suggestion is that we add something like the following
>>> to WorkerGlobalScope:
>>>
>>> String getAllCookies() - analogous to document.cookies in the DOM world
>>
>> No, this is a synchronous API which is not acceptible since it creates
>> a multithreaded environment for web developers. You need to use a
>> callback function.
>
> This can be even worse: how would you syncronize the code in the
> callback with code right after the call? You don't have any of
> semaphores or mutexes in ES and I don't expect them to be added soon.

I'm not sure I understand the problem you are describing. Could you
show an example using the APIs that exist in the spec today and with
an async cookie API added?

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

>
>
> No, this is a synchronous API which is not acceptible since it creates
> a multithreaded environment for web developers. You need to use a
> callback function.
>

Hmmm, I must've misinterpreted your previous statement:

>>> It seems like it should fine to allow reading cookies in dedicated
>>> workers though.

I'm sure I'm being obtuse, but I don't understand what you are saying here.

Let's imagine that I have a synchronous API - you are saying that this is
bad, because when I do this:

var cookies = self.getAllCookies();
doSomethingWithCookies(cookies);

The value of "cookies" may be out of date, so whatever
doSomethingWithCookies() is doing (like invoking an XHR request) may fail
because the cookies aren't accurate.

So, let's assume instead that we allow passing a callback to
getAllCookies():

self.getAllCookies( function(cookies) { doSomethingWithCookies(cookies); })

When doSomethingWithCookies() is invoked, whatever operation it is
performing may fail, because the passed-in value of cookies may still be out
of date.

Making getAllCookies() asynchronous means that the trivial fail case:

var a = getAllCookies();
var b = getAllCookies();
assert(a === b);

...can no longer fail because there's no return value. But fundamentally the
underlying problem continues to exist - the cookies may have changed behind
the scene, so whatever snapshot you have (either delivered synchronously or
asynchronously) may be out-of-date. So making getAllCookies() asynchronous
does not buy you anything, and additionally makes this API painful to use.

I think it's a laudable goal to try to shield developers from the
intricacies of accessing mutable global state, but I'm not sure that's
possible given that mutable global state exists and we want to allow
applications to access it from multiple threads.

As an aside, I wonder how a multi-process browser like Chrome handles
cookies even in the absence of workers - if I open two windows (separate
processes) under the same domain and set cookies in both, it seems like
there's an existing race condition.

-atw

Re: [whatwg] Accessing cookies from workers

[Giovanni Campagna]

2009/3/9 Jonas Sicking :
> On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson  wrote:
>>
>> On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking  wrote:
>>>
>>> However a much more interesting question is if sites would break if
>>> the above stopped being true. That is most definitely the case.
>>
>> Agreed - existing behavior trumps spec ambiguity. However, in this case I
>> was assuming that breaking existing sites was not an issue since we're
>> adding completely new functionality (accessing cookies from workers).
>> Existing sites won't break unless they add worker code that modifies
>> cookies, although perhaps that's a situation we need to avoid as well.
>
> I wouldn't expect new sites to be able to cope with this either. Even
> if we put in the spec that the value can change at any time, it is
> extremely unlikely that developers will deal with this appropriately.

They cannot deal with that, given they don't have any syncronization
mechanism outside the event system. To control the value of shared
variables, you need a lock on that variable while you're using it.

> See my analogy earlier in this thread regarding how hard it is to
> write multi-threaded code, even for expert C++ developers. It is
> definitely not something I would expect copy-n-paste web developers to
> get right.

If you don't understand the logics of multithreading, you should not
use workers (that are just ecmascript threads with a message queue),
IMHO.
>
>>> This is a very interesting suggestion. If we add a cookie access API
>>> then this would seem like a reasonable thing to require from that API.
>>>
>>
>> OK, to summarize, the suggestion is that we add something like the following
>> to WorkerGlobalScope:
>>
>> String getAllCookies() - analogous to document.cookies in the DOM world
>
> No, this is a synchronous API which is not acceptible since it creates
> a multithreaded environment for web developers. You need to use a
> callback function.

This can be even worse: how would you syncronize the code in the
callback with code right after the call? You don't have any of
semaphores or mutexes in ES and I don't expect them to be added soon.

> / Jonas
>

Giovanni

Re: [whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson  wrote:
>
> On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking  wrote:
>>
>> However a much more interesting question is if sites would break if
>> the above stopped being true. That is most definitely the case.
>
> Agreed - existing behavior trumps spec ambiguity. However, in this case I
> was assuming that breaking existing sites was not an issue since we're
> adding completely new functionality (accessing cookies from workers).
> Existing sites won't break unless they add worker code that modifies
> cookies, although perhaps that's a situation we need to avoid as well.

I wouldn't expect new sites to be able to cope with this either. Even
if we put in the spec that the value can change at any time, it is
extremely unlikely that developers will deal with this appropriately.
See my analogy earlier in this thread regarding how hard it is to
write multi-threaded code, even for expert C++ developers. It is
definitely not something I would expect copy-n-paste web developers to
get right.

>> This is a very interesting suggestion. If we add a cookie access API
>> then this would seem like a reasonable thing to require from that API.
>>
>
> OK, to summarize, the suggestion is that we add something like the following
> to WorkerGlobalScope:
>
> String getAllCookies() - analogous to document.cookies in the DOM world

No, this is a synchronous API which is not acceptible since it creates
a multithreaded environment for web developers. You need to use a
callback function.

/ Jonas

Re: [whatwg] Accessing cookies from workers

[Drew Wilson]

On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking  wrote:

>
> However a much more interesting question is if sites would break if
> the above stopped being true. That is most definitely the case.
>

Agreed - existing behavior trumps spec ambiguity. However, in this case I
was assuming that breaking existing sites was not an issue since we're
adding completely new functionality (accessing cookies from workers).
Existing sites won't break unless they add worker code that modifies
cookies, although perhaps that's a situation we need to avoid as well.

This is a very interesting suggestion. If we add a cookie access API
> then this would seem like a reasonable thing to require from that API.
>
>
OK, to summarize, the suggestion is that we add something like the following
to WorkerGlobalScope:

String getAllCookies() - analogous to document.cookies in the DOM world

void setCookie(newCookie, opt_callback) - sets cookies asynchronously, and
invokes the optional callback once the cookie state been set. Cookies are
guaranteed to be set before any subsequent network requests on that domain
are sent.

Thanks for the feedback.

-atw

[whatwg] Historic dates in HTML5

[Bruce Lawson]

Here are some (randomly selected) examples of microformats that are  
already being used to mark up historical dates in wikipedia, of the kind  
that would be illegal for 2 reasons; firstly, because they are not in the  
future, and also because they aren't precise (eg full -MM-DD format)  
or are ancient.


http://en.wikipedia.org/wiki/Public_Worship_Regulation_Act_1874
http://en.wikipedia.org/wiki/Septennial_Act_1715
http://en.wikipedia.org/wiki/George_Washington_Carver
http://en.wikipedia.org/wiki/John_Everett_Millais (birth date in hCard)
1066 has one hCalendar, with: 1066 :  
http://en.wikipedia.org/wiki/1066


In my opinion, in order for the time element to succeed, it must be  
capable of doing the same job as microformats, or - as Henri says - the  
time element will not succed.


Andy Mabbett has already listed use cases
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639.html

"Use-cases for machine-readable date mark-up are many: as well as the
aforesaid calendar interactions, they can be used for sorting; for
searching ("find me all the pages about events in 1923" — recent
developments in Yahoo's YQL searching API (which now supports searching
for microformats):

  

have opened up a whole new set of possibilities, which is only just
beginning to be explored). They can be mapped visually on a "SIMILE"

  

or similar time-line.  They can be translated into other languages more
effectively than raw prose; they can be disambiguated (does “5/6/09"
mean “5th June 2009? or “6th May 2009"?); and they can be presented
in the user's preferred format."

I suggest that the short list of apps that consume microformatted  
historical data should not be used to indicate that it's not a worthwhile  
use case. After all, I know of no user agents that can use time, section,  
footer, datagrid etc but we mostly expect there to be soon.



--
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)