Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
Oops. + list again. On Mon, Dec 13, 2010 at 6:35 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Dec 11, 2010 at 1:20 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Dec 10, 2010 at 7:27 AM, Jeremy Orlow jor...@chromium.org wrote: In addition to createObjectStore, I also intend to convert the following over: IDBObjectStore.createIndex Sounds good. IDBObjectStore.openCursor IDBIndex.openCursor IDBIndex.openKeyCursor I'm not convinced about these. It seems that this on average creates more syntax for authors rather than less. I see the main advantage with the options objects when you have so many arguments that it's hard to know which is which. Or when so many are optional that you end up having to specify the default value for a bunch just to specify the one you want to. In both cases these are of course fairly fuzzy limits. But it doesn't seem like either really applies here. I chatted with Brendan Eich about this and he made a good point. Do we know if all combinations are really going to be common? I.e. are all of the following going to be common: openCursor(); openCursor(range); openCursor(range, dir); openCursor(null, dir); If not, could we order the two optional arguments such that it's rare to need to specify the second, but not the first? My biggest concern is about the future, if we add more params. If we're not worrying at all about the future, then I'd probably agree that as is is best (since a cursor over everything backwards probably isn't super common). IDBKeyRange.bound On this one I feel rather strongly that option objects is overkill. Not only is it fairly clear what the arguments mean since they pair-wise match up to the two required arguments. I could even go with the following signature: IDBKeyRange bound( in any lower, in any upper, in optional boolean lowerOpen, in boolean upperOpen); That way you have to specify open-ness for both if you want to specify it for either. I didn't realize that was valid IDL and that's what it meant! Sure, you're probably right this is overkill. Requiring that they be in pairs or not be there at all seems reasonable. We did all of these two weeks ago in Chromium and have gotten some feedback. The main downside is that typos are silently ignored by JavaScript. We considered throwing if someone passed in an option we didn't recognize, but this would make it impossible to add more options later (which is one of the main reasons for doing this change). I think what we might do is just log something in the console with this happens. (Should the spec actually make a recommendation to this effect?) Besides that, I think overall we're happy with the change. I'm with Pablo here. It seems unlikely that we'd introduce an argument in the future which we'd want old implementations to just silently ignore. For example, if we add 'required' as a boolean argument to createIndex in v2, I'd think we'd want an implementation which doesn't support that to throw. Similarly, if we add 'expression' as a way to solve bug 1, we'd want a v1 implementation to throw, no? You're probably right, but how should we tell people to detect whether certain implementations support certain features? (Try/catches? That seems pretty ugly.) Lastly, are we happy with all the variable names for the above functions being directly turned into parameter names for the options object? If not, please enumerate any changes you think we should do. Sounds good to me. / Jonas
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
Btw, I forgot to mention IDBDatabase.transaction which I definitely think should take an options object as well. On Tue, Dec 14, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: Oops. + list again. On Mon, Dec 13, 2010 at 6:35 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Dec 11, 2010 at 1:20 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Dec 10, 2010 at 7:27 AM, Jeremy Orlow jor...@chromium.org wrote: In addition to createObjectStore, I also intend to convert the following over: IDBObjectStore.createIndex Sounds good. IDBObjectStore.openCursor IDBIndex.openCursor IDBIndex.openKeyCursor I'm not convinced about these. It seems that this on average creates more syntax for authors rather than less. I see the main advantage with the options objects when you have so many arguments that it's hard to know which is which. Or when so many are optional that you end up having to specify the default value for a bunch just to specify the one you want to. In both cases these are of course fairly fuzzy limits. But it doesn't seem like either really applies here. I chatted with Brendan Eich about this and he made a good point. Do we know if all combinations are really going to be common? I.e. are all of the following going to be common: openCursor(); openCursor(range); openCursor(range, dir); openCursor(null, dir); If not, could we order the two optional arguments such that it's rare to need to specify the second, but not the first? My biggest concern is about the future, if we add more params. If we're not worrying at all about the future, then I'd probably agree that as is is best (since a cursor over everything backwards probably isn't super common). IDBKeyRange.bound On this one I feel rather strongly that option objects is overkill. Not only is it fairly clear what the arguments mean since they pair-wise match up to the two required arguments. I could even go with the following signature: IDBKeyRange bound( in any lower, in any upper, in optional boolean lowerOpen, in boolean upperOpen); That way you have to specify open-ness for both if you want to specify it for either. I didn't realize that was valid IDL and that's what it meant! Sure, you're probably right this is overkill. Requiring that they be in pairs or not be there at all seems reasonable. We did all of these two weeks ago in Chromium and have gotten some feedback. The main downside is that typos are silently ignored by JavaScript. We considered throwing if someone passed in an option we didn't recognize, but this would make it impossible to add more options later (which is one of the main reasons for doing this change). I think what we might do is just log something in the console with this happens. (Should the spec actually make a recommendation to this effect?) Besides that, I think overall we're happy with the change. I'm with Pablo here. It seems unlikely that we'd introduce an argument in the future which we'd want old implementations to just silently ignore. For example, if we add 'required' as a boolean argument to createIndex in v2, I'd think we'd want an implementation which doesn't support that to throw. Similarly, if we add 'expression' as a way to solve bug 1, we'd want a v1 implementation to throw, no? You're probably right, but how should we tell people to detect whether certain implementations support certain features? (Try/catches? That seems pretty ugly.) Lastly, are we happy with all the variable names for the above functions being directly turned into parameter names for the options object? If not, please enumerate any changes you think we should do. Sounds good to me. / Jonas
Re: Call for Editors for Server-sent Events, Web Storage, and Web Workers
On Mon, Dec 13, 2010 at 3:42 PM, Doug Schepersschep...@w3.org wrote: But we are looking for more than someone to just push TR copies, we want someone who (like Ian) understands the issues, and knows how to help drive progress through consensus and technical expertise, and who can dedicate themselves to the task. Can we get a bullet-point listing of the responsibilities for the desired position? I've gone back and reread the OP, and I don't understand what exactly you're asking for. I'm sure the responsibilities are hidden there, but the wordiness makes my eyes slide right over them. Doug - thanks for starting this thread. Tab - Doug indicated some of the tasks in the head of this thread: [[ http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0919.html 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. ]] The thread Doug alludes to above included some additional tasks: [[ http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0860.html All of these specs have a Bugzilla component for issue and comment tracking, all are included in the WHATWG issue tracker at [Issues], all of the specs have changed since their LC was published and all of the specs had at least one comment submitted against the LC via public-webapps. With respect to does a spec need to return to LC or can it advance to Candidate?, Section 7.4.6 of W3C process says: ... Since Hixie is active on HTML, perhaps someone else is willing to pick one of these LCs and to review the issues, bugs, diffs, etc. and propose the next step . [Issues] http://www.whatwg.org/issues/ ]] I realize the W3C process can be a bit heavy weight, especially regaring LC comment processing and if you or anyone else can help, that would be great. I don't think it is fair or reasonable to expect Hixie to do all of the work required to move a spec through the W3C process. -Art Barstow
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. If you indeed keep using includes/locked, attributes, and pseudo from the template, you end up with a semi-live template, where modifications to those values could affect the instances. I think you'd be better off with something like this: * Each bound instance holds data on how information (attribute values, nodes, CSS pseudo-elements matching, etc.) is forwarded from the bound element down to the the shadow subtree. * During the binding phase, this information is populated by reading corresponding attributes on the template. This approach allows: * Having a clean break between templates and instances. * Allowing bound behaviors manipulate their forwarding at will, without affecting the template. Here's a mental model I would present to Web developers: * The ability to influence a shadow DOM subtree from the outside is provided by the Shadow DOM Forwarding. * It's a list (array) of rules you associate with to the shadow DOM. * Each rule specifies how a node, an attribute, a text node, current language (and possibly direction), or a CSS pseudo selector is forwarded from the bound element to the elements in the shadow subtree. * You can create this set of rules imperatively during the binding phase, or * You can use templates to wire this up declaratively. * You can modify the rules at any time while the shadow subtree exists, but changes to rules are not retroactive. * In other words, what's been forwarded is not re-forwarded or affected in any way once the forwarding rule is changed or removed. WDYT? But yeah, we're agreeing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. But yeah, we're agreeing. Begging the question. ^_^ All of the information from the template can be duplicated in appropriate data structures on the element itself, like Dimitri explains. This allows us to treat the template solely as a stamp, used only at initialization and then thrown away. This gains us a few things. For one, you now have a simpler, more static model of how things work. There's no action-at-a-distance where changes to the template late in the page lifecycle can affect elements created during the original page parse; once an element is created with the appropriate information, it stays that way forever, unless the author explicitly monkeys around with it. For two, it naturally exposes all the magical template abilities to plain javascript, allowing everything to be manipulated by script after-the-fact, or even done entirely through script if that is, for whatever reason, easier than writing a template into a page. I think this is A Good Thing(tm). In general, I don't think we shouldn't be adding new magical features to the platform without ensuring they can be handled in script as well. Looking just at the problem itself, it's an open question as to whether it would be simpler to hold a reference to the template or just create the appropriate data structures out of the template. Likely, you'll be doing the latter in C++ anyway, so pushing them out into js as well feels pretty natural. But with the other added benefits that you get from making everything happen out in the open, I think the decision is a lot clearer. ~TJ
Re: XBL2: First Thoughts and Use Cases
On 12/14/10 10:25 AM, Tab Atkins Jr. wrote: Looking just at the problem itself, it's an open question as to whether it would be simpler to hold a reference to the template or just create the appropriate data structures out of the template. Likely, you'll be doing the latter in C++ anyway, so pushing them out into js as well feels pretty natural. Wait. Are we talking about exposing details about the template to JS somewhere? Where? And why? -Boris
Re: XBL2: First Thoughts and Use Cases
On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:23 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:16 AM, Dimitri Glazkov wrote: This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? The issues we've run into is that the shadow DOM tree can get mutated, which makes the actual DOM get out of sync with the data structures that represent insertion points (what I think XBL2 calls output ports) and the like). After this, adding normal DOM children to the bound element at best puts them in the wrong place in the shadow DOM; at worst we've had exploitable crash issues we had to fix. Hmm. I'm not well-versed enough in XBL1 to understand what all the difficulties are, but what we're envisioning is pretty simple and shouldn't lead to many problems. Given a template with some output ports, it's instantiated by cloning the shadow DOM and then setting up a map of selectors-shadow-nodes to represent the output ports. If you mutate the shadow DOM without paying attention to the outputPorts map, there are three possibilities for each port: 1. It points to a shadow node that wasn't mutated. No change. 2. It points to a shadow node that was moved. Everything currently attached to that shadow node, and any new elements added to the component which match the selector, will show up wherever the shadow node was moved to. 3. It points to a shadow node that was removed. Existing normal nodes which were pointing to that shadow node now don't show up at all in the final flattened tree (they lose their attachment, unless you ask for them to be reattached). New elements that get added and which match the selector can either ignore the selector (because we know that port is invalid) or just explicitly get put nowhere in the final flattened tree. Either option would be fine with me. Now if the shadow DOM can only be mutated by the binding itself, then it's possible to just avoid those problems in the binding script or restrict the things that script can do. But if the shadow DOM is exposed to the page the bound element is in, then the implementation needs to handle arbitrary mutations _somehow_, since you can't rely on things outside the binding playing nice with the binding. Or, of course, restrict what _that_ script can do with the shadow DOM, but that has more potential for weird breakage if the binding changes out from under the scripts that are trying to poke at it. All of the cases I outlined above can be run into when you're mutating a live template as well. Are there additional cases I'm missing that you have problems with? Are they perhaps a result of having both a mutable shadow and a live template? ~TJ
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow jor...@chromium.org wrote: Btw, I forgot to mention IDBDatabase.transaction which I definitely think should take an options object as well. Hmm.. I think we should make the first argument required, I actually thought it was until I looked just now. I don't see what the use case is for opening all tables. In fact, it seems rather harmful that the syntax which will result in more lock contention is simpler than the syntax which is better optimized. This leaves two optional arguments, the second of which is likely very rarely going to be used. In fact, I wouldn't mind removing it entirely since it just seems like it risks causing race conditions. And it's technically syntax sugar since you can always use setTimeout and call .abort() manually. / Jonas
[Bug 11552] New: We should remove timeout from IndexedDB.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11552 Summary: We should remove timeout from IndexedDB. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should remove timeout from IndexedDB. Per the mailing list thread resulting from bug 11398. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow jor...@chromium.org wrote: Btw, I forgot to mention IDBDatabase.transaction which I definitely think should take an options object as well. Hmm.. I think we should make the first argument required, I actually thought it was until I looked just now. I don't see what the use case is for opening all tables. FWIW I'm finding that the majority of the IndexedDB code I read and write does indeed need to lock everything. I'm also finding that most of the code I'm writing/reading won't be helped at all by defaulting to READ_ONLY... In fact, it seems rather harmful that the syntax which will result in more lock contention is simpler than the syntax which is better optimized. But you're right about this. So, if we're trying to force users to write highly parallelizable code, then yes the first arg probably should be required. But if we're trying to make IndexedDB easy to use then actually the mode should probably be changed back to defaulting to READ_WRITE. I know I argued for the mode default change earlier, but I'm having second thoughts. We've spent so much effort making the rest of the API easy to use that having points of abrasion like this seem a bit wrong. Especially if (at least in my experience) the abrasion is only going to help a limited number of cases--and probably ones where the developers will pay attention to this without us being heavy-handed. This leaves two optional arguments, the second of which is likely very rarely going to be used. In fact, I wouldn't mind removing it entirely since it just seems like it risks causing race conditions. And it's technically syntax sugar since you can always use setTimeout and call .abort() manually. Removing timeout SGTM. J
Rename XBL2 to something without X, B, or L?
Dear all, 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? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of HTML, it probably should lose an 'L'. As for 'B', describing what XBL2 aims to do as 'bindings' ain't super-accurate. The way I look at it, the problems we're trying to solve are: a) templating -- for astoundingly fast creation of DOM chunks using declarative syntax; b) shadow DOM -- for maximum-pleasure encapsulation and leak-free component abstraction of DOM chunks; c) binding -- for joy-filled extension and decoration DOM elements. Describing all these as just Binding just feels wrong. Web Components perhaps or something along these lines? Who's with me? :) :DG
Re: Rename XBL2 to something without X, B, or L?
I'm with you :-) I really dislike the current name, and it keeps reminding me of XBEL, the bookmark exchanging language. Kenneth On Tue, Dec 14, 2010 at 10:24 PM, Dimitri Glazkov dglaz...@google.com wrote: Dear all, 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? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of HTML, it probably should lose an 'L'. As for 'B', describing what XBL2 aims to do as 'bindings' ain't super-accurate. The way I look at it, the problems we're trying to solve are: a) templating -- for astoundingly fast creation of DOM chunks using declarative syntax; b) shadow DOM -- for maximum-pleasure encapsulation and leak-free component abstraction of DOM chunks; c) binding -- for joy-filled extension and decoration DOM elements. Describing all these as just Binding just feels wrong. Web Components perhaps or something along these lines? Who's with me? :) :DG -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆
Re: Rename XBL2 to something without X, B, or L?
On Tue, Dec 14, 2010 at 1:24 PM, Dimitri Glazkov dglaz...@google.com wrote: Dear all, 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? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of HTML, it probably should lose an 'L'. As for 'B', describing what XBL2 aims to do as 'bindings' ain't super-accurate. The way I look at it, the problems we're trying to solve are: a) templating -- for astoundingly fast creation of DOM chunks using declarative syntax; b) shadow DOM -- for maximum-pleasure encapsulation and leak-free component abstraction of DOM chunks; c) binding -- for joy-filled extension and decoration DOM elements. Describing all these as just Binding just feels wrong. Web Components perhaps or something along these lines? Who's with me? :) I'm partial to Web Component Model. This lends a good name to the things that use it (components), and is pretty clear I think. ~TJ
Re: Rename XBL2 to something without X, B, or L?
On 12/14/2010 01:24 PM, Dimitri Glazkov wrote: Dear all, 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? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of HTML Is it? That was just a proposal, but I prefer the spec before the latest editions. -Olli , it probably should lose an 'L'. As for 'B', describing what XBL2 aims to do as 'bindings' ain't super-accurate. The way I look at it, the problems we're trying to solve are: a) templating -- for astoundingly fast creation of DOM chunks using declarative syntax; b) shadow DOM -- for maximum-pleasure encapsulation and leak-free component abstraction of DOM chunks; c) binding -- for joy-filled extension and decoration DOM elements. Describing all these as just Binding just feels wrong. Web Components perhaps or something along these lines? Who's with me? :) :DG
RE: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 5:03 AM I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. It sounds like a good idea to keep QUOTA_ERR separated from other general errors that come up when writing stuff to disk. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) That sounds reasonable to me. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? I don't think it's a big deal, but are we going to have a bunch of unimplemented stuff across browsers? If this becomes common, I wonder if we should have a separate error so calling code can choose to compensate or something. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? NOT_ALLOWED_ERR? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Sure. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I'm fine with that. -pc
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On Wed, Dec 15, 2010 at 12:08 AM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 5:03 AM I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. It sounds like a good idea to keep QUOTA_ERR separated from other general errors that come up when writing stuff to disk. I'll re-add it then. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) That sounds reasonable to me. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? I don't think it's a big deal, but are we going to have a bunch of unimplemented stuff across browsers? If this becomes common, I wonder if we should have a separate error so calling code can choose to compensate or something. Hopefully it won't be a big deal. I think most browsers are a bit more fast and loose with shipping half working things before anyone else has shipped something rock solid (that people are using in production). I expect that our couple instances of this will go away pretty soon. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? NOT_ALLOWED_ERR? Shawn said NOT_FOUND_ERR. NOT_ALLOWED_ERR seems slightly better to me. Shawn, what do you think? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Sure. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I'm fine with that. -pc
RE: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Friday, December 10, 2010 1:42 PM On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow jor...@chromium.org wrote: Any more thoughts on this? I don't feel strongly one way or another. Implementation wise I don't really understand why implementations couldn't use keys of unlimited size. I wouldn't imagine implementations would want to use fixed-size allocations for every key anyway, right (which would be a strong reason to keep maximum size down). I don't have a very strong opinion either. I don't quite agree with the guideline of having something working slowly is better than not working at all...as having something not work at all sometimes may help developers hit a wall and think differently about their approach for a given problem. That said, if folks think this is an instance where we're better off not having a limit I'm fine with it. Pablo, do you know why the back ends you were looking at had such relatively low limits? Mostly an implementation thing. Keys (and all other non-blob columns) typically need to fit in a page. Predictable perf is also nice (no linked lists, high density/locality, etc.), but not as fundamental as page size. -pablo
Re: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
On Wed, Dec 15, 2010 at 12:19 AM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Friday, December 10, 2010 1:42 PM On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow jor...@chromium.org wrote: Any more thoughts on this? I don't feel strongly one way or another. Implementation wise I don't really understand why implementations couldn't use keys of unlimited size. I wouldn't imagine implementations would want to use fixed-size allocations for every key anyway, right (which would be a strong reason to keep maximum size down). I don't have a very strong opinion either. I don't quite agree with the guideline of having something working slowly is better than not working at all...as having something not work at all sometimes may help developers hit a wall and think differently about their approach for a given problem. That said, if folks think this is an instance where we're better off not having a limit I'm fine with it. My only concern is that the developer might not hit this wall, but then some user (doing things the developer didn't fully anticipate) could hit that wall. I can definitely see both sides of the argument though. And elsewhere we've headed more in the direction of forcing the developer to think about performance, but this case seems a bit more non-deterministic than any of those. Pablo, do you know why the back ends you were looking at had such relatively low limits? Mostly an implementation thing. Keys (and all other non-blob columns) typically need to fit in a page. Predictable perf is also nice (no linked lists, high density/locality, etc.), but not as fundamental as page size. -pablo
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On 12/14/2010 4:16 PM, Jeremy Orlow wrote: Shawn said NOT_FOUND_ERR. NOT_ALLOWED_ERR seems slightly better to me. Shawn, what do you think? I don't have a strong opinion either way. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
[Bug 11553] New: Ensure indexedDBSync is on the right worker interface
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11553 Summary: Ensure indexedDBSync is on the right worker interface Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org I just noticed that the async part of the spec has indexedDB in Worker (i.e. Worker implements IDBEnvironment), whereas the sync API has it WorkerUtils. The second one is probably just old, so for my current editing pass (bringing sync/async in sync) I'll just change it to Worker for consistency. However, from looking at the Web Workers spec [1] it seems that IDBEnvironmentSync should be implemented by AbstractWorker so it's available in regular and shared workers. Is that right? If not, what's the right spot? [1] http://dev.w3.org/html5/workers -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
