- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 7 Dec 2009 14:34:37 +0000 (UTC)
- To: Maciej Stachowiak <mjs@apple.com>, Marcos Caceres <marcosc@opera.com>
- Cc: Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On Mon, 7 Dec 2009, Maciej Stachowiak wrote: > > Note though: process-wise, Web Storage being in LC *is* a blocker to the > Widgets specification going to REC. Per W3C Process, a specification > cannot go to PR or REC unless all of its dependencies are at REC. It's > true though that it would not be a blocker to going to CR. As far as I can tell (from our discussion on IRC and from my memory of the requirements), there is a pubrules suggestion that CR specs should only depend on CR+ specs, and PR specs should only depend PR+ specs, but it's neither a hard rule, nor in the W3C process. On Mon, 7 Dec 2009, Marcos Caceres wrote: > On Mon, Dec 7, 2009 at 7:14 AM, Ian Hickson <ian@hixie.ch> wrote: > > On Mon, 7 Dec 2009, Marcos Caceres wrote: > >> > >> Sorry Ian, you are assuming you are the only one that can edit that > >> spec. If you want help with editing the spec or with the test suite, > >> just ask. I'm not saying I'll do it, but I can ask at Opera for one > >> of the WHATWG superstars to take it over. WDYT? or is it just too > >> entangled in HTML 5 to let someone else edit it? > > > > If Opera has people who have time to edit, there are _far_ more > > important things for us to have edited than Web Storage. DOM Core, for > > instance. > > No offense, but I didn't know Google dictated Opera's, an other > companies, business objectives :) The "us" in my statement above was meant to refer to the Web at large, not Google. I'm not trying to dictate your business objectives, but from the perspective of the Web's overall health, having DOM Core edited would be far more valuable than having Web Storage go to CR early. > > Anyway, my point was that even if I did have time to edit the spec, it > > would be a bad idea to accelerate the process. Reviewing a spec takes > > time, finding problems takes time, and if we rush it we'll just screw > > it up. > > Yes, I totally got that and completely agree. However, we have a number > of people that have implemented this that could be pressed for feedback. Implementors of Web Storage have sent plenty of feedback. I'm confident that there are no known issues currently other than the storage mutex issue. Problems can't be squeezed out at will -- they take time to discover. Shortening the Last Call window to make progress faster is like trying to shorten the baking time for a cake by cooking it hotter. What you get in the end doesn't smell nice. > Also, creating a test suite for Web Storage would allow us to find at > least some spec bugs quickly which someone else could fix in the spec > while you are busy with HTML5 and the other specs you are working on. > Might help cut a month or two from your work schedule. Yes, if anyone would like to write a test suite, that would be extremely useful, independent of the Last Call window. As the spec's editor I don't think it would be wise for me to write the test suite anyway (since I'd end up writing tests that check what I think the spec says, not what it actually says). > Again, if you need some help with something, please ask. It doesn't need > to be editing, it could be test suite or whatever. A test suite and a solution to the storage mutex problem that all the browser vendors are willing to implement (which doesn't break the API and which doesn't introduce subtle bugs) would both be extremely helpful in accelerating the process after LC. Test suites for the other specs in this batch would also be awesome. > > Web Storage in particular has _already_ resulted in one of the biggest > > screwups of the last few years in the Web standards space (for which I > > take full responsibility) because of rushing implementations. > > Cheer up, I can think of _much_ worst things that have popped out of the > W3C onto the Web than Web Storage:) Yeah but they typically have minimal impact on the deployed Web, unlike the storage mutex problem. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 7 December 2009 14:35:07 UTC