Re: [IndexedDB] Do we need a timeout for VERSION_CHANGE?
In another thread (in the last couple days) we actually decided to remove timeouts from normal transactions since they can be implemented as a setTimeout+abort. But I agree that we need a way to abort setVersion transactions before getting the callback (so that we implement timeouts for them as well). Unfortunately, I don't immediately have any good ideas on how to do that though. J On Wed, Dec 15, 2010 at 10:46 PM, Pablo Castro pablo.cas...@microsoft.comwrote: Regular transactions take a timeout parameter when started, which ensures that we eventually make progress one way or the other if there's an un-cooperating script that won't let go of an object store or something like that. I'm not sure if we discussed this before, it seems that we need to add a similar thing for setVersion(), and it's basically a way of starting a transaction. I was thinking we could have an optional timeout argument in setVersion with a UA-specific default. In the async case we would fire the onerror event and in the sync case just throw, both with TIMEOUT_ERR. Thanks -pablo
Re: Rename XBL2 to something without X, B, or L?
On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote: Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? I strongly object. We have a long and proud tradition of perfectly horrible and meaningless names such as XMLHttpRequest. I don't see why we'd ever have to change. Shadow HTML Anonymous DOm for the Web! -- Robin Berjon - http://berjon.com/
Re: Rename XBL2 to something without X, B, or L?
On Thu, 16 Dec 2010 14:51:39 +0100, Robin Berjon ro...@berjon.com wrote: On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote: Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? I strongly object. We have a long and proud tradition of perfectly horrible and meaningless names such as XMLHttpRequest. I don't see why we'd ever have to change. Shadow HTML Anonymous DOm for the Web! Cause I know you are being serious I will be serious as well and point out that XMLHttpRequest's name is legacy bound as that is what implementations call it and applications are using. XBL2 has none of that. -- Anne van Kesteren http://annevankesteren.nl/
答复: Call for Editors for Server-sent Events, Web Storage, and Web Workers
Hi Doug and All， I am Pan Songbai, from Chinaunicom which is one of the largest telecom company in China， now I am studying key-Vale database and interested in W3C spec， so I want to become an editor，Thanks. Best regards, Cooper /* 潘松柏 * 中国联通集团研究院 * Tel: 010-6879-9587; 186-0110-3003 * Mail: pan...@chinaunicom.cn */ -邮件原件- 发件人: member-webapps-requ...@w3.org [mailto:member-webapps-requ...@w3.org] 代表 Doug Schepers 发送时间: 2010年12月14日 5:16 收件人: public-webapps@w3.org 主题: Call for Editors for Server-sent Events, Web Storage, and Web Workers Hi, Folks- This is an active call for editors for the Server-sent Events [1], Web Storage [2], and Web Workers [3] specifications. If you are interested in becoming an editor, with all the rights and responsibilities that go along with that, please respond on this thread or email us directly at team-weba...@w3.org. Previously, Art Barstow asked for an analysis of the current status of these specs, with regards to LC comments, implementations, test suites, and so forth; these are typically performed and coordinated by the editor of a spec, and it's appropriate that someone doing this work would get editor credit for their effort. These specs have not made progress along the Recommendation track in some time, and we want to move them forward to a stable state. We appreciate and acknowledge the work the current editor, Ian Hickson, has put into these specs, but he seems to have indicated that he does not wish to be the one to drive them forward (which is understandable, given his other commitments, such as the HTML5 spec). Ideally, we would prefer that Ian stay on as active co-editor, but if the logistics don't work out, we may ask the new co-editor to take on the sole responsibility for finalizing the spec, including processing comments from the WebApps WG, and from the community at large. In the earlier thread, there was a discussion on the logistics and differing philosophies on spec development; without dwelling on that topic too much, it's worth stating that stability of a spec is a goal not only for licensing commitments, but also as a matter of coordination with multiple implementers, and for development of the entire infrastructure around a technology, including tests, tutorials, script libraries, and cutting-edge usage, some of which happens within W3C, and some of which happens in the wild. We have an obligation to our community to make clear and consistent statements on the stability of our documents, because it costs real time, effort, and money to invest in these technologies. Secure and efficient specifications are obviously the most important goal, but pushing out deadlines and changing the spec without clear progress toward a stable state is frustrating and troublesome for our community. There is a difference in strategies between Ian's stated approach and W3C's; both are valid, but W3C has chosen to publish stable snapshots of specifications in the form of Recommendations, and to release updates to those technologies as subsequent editions, or to build upon them with new versions or levels. This is the expectation in the WebApps WG, so we are calling for active co-editors who will dedicate themselves to the task of driving these specs to a stable state in a reasonable and predictable timeframe. [1] Server-sent Events http://www.w3.org/TR/2009/WD-eventsource-20091222/ [2] Web Storage http://www.w3.org/TR/2009/WD-webstorage-20091222/ [3] Web Workers http://www.w3.org/TR/2009/WD-workers-20091222/ Regards- Doug Schepers, W3C Team Contact Art Barstow (Nokia), Co-Chair Charles McCathieNevile (Opera), Co-Chair,
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. -Boris
Re: XBL2: First Thoughts and Use Cases
On 12/15/10 10:53 PM, Maciej Stachowiak wrote: Are they really contradictory? Good question. ;) If they aren't, great. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Right; I think we're on the same page there. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. Well, at least with XBL1 modifying the shadow tree is very common. And I would assume that to be rather common with XBL2 too. -Olli ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. That's why Hixie made XBL2's templates always-live, I think. But I totally get the need of coming up with a solution that doesn't end up being a memory hog. :DG -Boris
Re: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 10:53 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: At least in Gecko's case, we still use XBL1 in this way, and those design goals would apply to XBL2 from our point of view. It sounds like you have entirely different design goals, right? Sounds like it. OK, so given contradictory design goals, where do we go from here? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. FWIW, I think Tab agrees with you here (right, Tab? :). If you want to introduce new capabilities, might as well make them lean and mean. :DG Regards, Maciej
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 12:23 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. Well, at least with XBL1 modifying the shadow tree is very common. And I would assume that to be rather common with XBL2 too. Yes. -Olli ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/16/10 1:00 PM, Dimitri Glazkov wrote: I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/16/10 1:00 PM, Dimitri Glazkov wrote: I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. Hmm. Olli just said that shadow mutations are common in XBL1. I'm somewhat loathe to make it automatically dead. On the other hand, there are lots of use-cases where dead shadows are perfectly fine, so having some declarative way to differentiate between whether the shadow needs to be live or dead might work. For example, adding resize handles to an image doesn't require a live shadow. The handles can be static; they'll need listeners registered on them, but that's it. Same with video controls, or select substructure. It sounds like it's fine for the shadow to mutate, so long as nodes aren't added/created/moved. For example, I can twiddle attributes on a shadow node without requiring the more expensive map all the metadata out step, right? The idea is just that we can, as an optimization, keep all the metadata on a central shared object, so that any time I, say, add a normal-DOM node to a component, I can just go check that central data object to see where to forward the node? ~TJ
RE: [IndexedDB] Do we need a timeout for VERSION_CHANGE?
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Thursday, December 16, 2010 2:35 AM In another thread (in the last couple days) we actually decided to remove timeouts from normal transactions since they can be implemented as a setTimeout+abort. But I agree that we need a way to abort setVersion transactions before getting the callback (so that we implement timeouts for them as well). Unfortunately, I don't immediately have any good ideas on how to do that though. Sorry, forgot to qualify it, context == sync api. I assume that the sync versions of the API will truly block, so setTimeout won't do as code won't just reenter into the timeout callback while blocked on a sync IndexedDB call, are we all on the same page on that? If that's the case, then I don't think we can remove the timeout parameter from the sync versions of transaction() and setVersion(). Does that sound reasonable? I'll add them for now, we can adjust if somebody come up with a better approach. As for setVersion in async...that's actually a problem as well now that I think about it because you don't have access to the (version) transaction object until it actually was able to start. One option besides having a timeout parameter in the method would be to have an abort() method in IDBVersionChangeRequest. Thanks, -pablo
[IndexedDB] KeyRange factory methods
I was going to file a bug on this but wanted to make sure I'm not missing something first. All the factory methods for ranges (e.g. bound, lowerBound, etc.) are in the IDBKeyRangeConstructors interface now, but I don't see the interface referenced anywhere. Who implements this interface, the Window object, IDBFactory[Sync], something else? Thanks -pablo
