RE: Race conditions in HTML 5?

Ian Hickson wrote:

> > and probably need to allow some HTML author control over execution
> > order, if it's to be effective.
> 
> I don't really see why.

Well, CPU and network efficiency for two. In a native application,
I would want to retrieve server data before updating the local cache.
If the web application updates the cache, then retrieves network 
data, then updates the cache again, the first update was a waste.

Usability seems likely to improve as well: if the application isn't 
slowed down writing old information to local cache right before
getting updated information from the network, users should see the
application as starting more quickly.

> Browsers already use this model, and it has
> worked without problems so far.

Actually, the apparent newness of it in a specification was exacty what
caught my attention. For example, I don't see anything similar in the
spec for the createXMLHttpRequest function. [1]

I can't find anything in the HTML 4 or DOM 3 standards that calls for 
this "all other scripts have stopped executing" behavior. Where has
this been specified in the past?

[1] http://www.w3.org/TR/XMLHttpRequest/

Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch] 
> Sent: Tuesday, June 10, 2008 3:03 PM
> To: Bonner, Matt
> Cc: Boris Zbarsky; Jim Jewett; HTML WG
> Subject: RE: Race conditions in HTML 5?
> 
> On Tue, 10 Jun 2008, Bonner, Matt wrote:
> >
> > Ian Hickson wrote:
> > > So do I; if you search the source of the document you'll find the
> > > occasional mention of a queue in the comments. I haven't 
> figured out
> > > exactly where it should go yet but basically anything 
> that waits for
> > > scripts to finish, including in particular event firing, 
> callbacks,
> > > and timers, will use this queue.
> >
> > A page-global execution queue could work as a solution, but 
> will require
> > considerable specification
> 
> That's not a problem.
> 
> 
> > and probably need to allow some HTML author control over execution
> > order, if it's to be effective.
> 
> I don't really see why. Browsers already use this model, and it has
> worked without problems so far.
> 
> 
> > One can imagine without trouble an web application author wanting e.g.
> > the event-source script to execute (retrieving data) before the
> > application cache script (saving application state locally), but the
> > <html> cache manifest would of course appear first in the HTML file.
> 
> They would execute not based on the order they appear in the file, but in
> the order that the network responds, so I don't see this as a problem.
> 
> 
> The queueing issue is on my list; see the bottom of this list 
> of e-mails:
> 
>    http://www.whatwg.org/issues/#scripts-misc
> 
> (The ones labelled "Race conditions in HTML 5?".)
> 
> 
> > I must agree with Laura Carlson, a clear explanation of the issue
> > tracking process would be a great help.
> 
> Yeah, I have to admit that at this point I'm rather confused 
> about where
> I'm supposed to be looking to have an unambiguous list of issues to go
> through. Originally it was the wiki, then people put lots of 
> placeholder
> pages on there so it became no longer a clear list. Then we added the
> tracker, but then people added issues that the WG hadn't 
> discussed, and
> people objected when I marked issues as issues I'd dealt with 
> to the best
> of my ability. Now we also have a Bugzilla issue tracker. At 
> this point I
> really have no idea what I'm supposed to be doing. It would 
> be useful if
> the chairs could give me an unambiguous URL where I can see 
> the list of
> issues I'm expected to go through, and a way to take them off the list
> that I see; and if people had a clear set of steps for how to 
> add things
> to the list.
> 
> In the meantime, if people want to raise issues in an unambiguous way,
> sending an e-mail to the WHATWG list is a way to guarantee that I will
> consider the feedback and send a reply. You can join this list here:
> 
>    http://www.whatwg.org/mailing-list#specs
> 
> The list of open issues opened in that manner is visible here:
> 
>    http://www.whatwg.org/issues/
> 
> However, I really would like the issue tracking process to be 
> clarified so
> that we can make productive progress in the working group.
> 
> --
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
>

Received on Thursday, 12 June 2008 00:50:50 UTC