Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters sim...@opera.com wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org wrote: Just to confirm, we don't want the events to propagate to the window itself, right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request-transaction-database. This goes for both success and error events. However success doesn't bubble so normal event handlers doesn't fire on the transaction or database for success. But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For abort events the propagation path is just transaction-database since the target of abort events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an error event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing error handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. Hmm. I'm not sure what to think of IndexedDB using window.onerror. window.onerror is used for catching JS syntax errors and uncaught exceptions in scripts. Also, window.onerror is invoked directly without firing an actual event. Not just syntax errors. At least in firefox it also fires for uncaught exceptions. That's what I said. :-) So basically we fire all javascript errors which goes unhandled by the page (there is no way to handle syntax errors so they always goes unhandled). That is very much the case here, however since the error reporting must be asynchronous we report it using a event rather than an exception. What's the use case for firing an error event on window for IndexedDB? What is the use case for error events? I've always thought of it as a choke point where pages can catch JS errors and either display to the user or report back to the server for debugging. If that is the case then this is just another case where errors can arise. Do you have another use case in mind? There are lots of errors in the Web platform that are not reported to window.onerror: link style script img object video source track input ApplicationCache Worker SharedWorker EventSource WebSocket frame Should any of those also fire an event to window.onerror as their error event's default action? All of them? What I'm trying to do is to get some consistency so the Web platform doesn't appear so designed by committee where half the errors are reported to window.onerror and the other half not. It makes stuff harder to learn. This is similar to how error events are handled in workers. Not really. Workers have their own onerror handler in the worker script itself, and if the error is still not handled, an error event is fired on the worker object, but it stops there; an error event is never fired on window. That's not the case in the gecko implementation. But I see the spec doesn't call for this yet. I'll file a bug on the spec. OK. Opera follows the spec, FWIW. -- Simon Pieters Opera Software
Re: [webstorage] Moving Web Storage back to Last Call WD
On Sat, 12 Feb 2011, Arthur Barstow wrote: What high priority work must be done such that this spec is ready to be re-published as a new Last Call Working draft? Tab, do you know of anything that is blocking redoing an LC? (Personally I'm fine with it going to REC yesterday, so...) Bugzilla shows no open bugs for this spec [Bugs] and the latest ED includes the following: [[ The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after. If reviewers have any suggestions, they are urged to send them to the addresses given in the previous section. [...] ]] In particular, what are the proposals, plans and timeline to address the above issues? There is no proposal to address the issue. The plan is to wait for someone to have an idea. The timeline is thus open-ended. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [workers] Moving the Web Workers spec back to Last Call WD
On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Web Workers spec [ED] as a new Last Call Working Draft ... Bugzilla shows one open bug [Bugs]: 11818 - As documented in the Creating workers section, a worker *must* be an external script. http://www.w3.org/Bugs/Public/show_bug.cgi?id=11818 What high priority work must be done such that this spec is ready to be re-published as a new Last Call Working draft? None, to my knowledge. The bug above is a feature request. In particular, what are the proposals, plans and timeline to address the above bug? I expect to address the issue of supporting data: URL scripts in workers at the same time as adding the ability to do cross-origin shared workers, currently estimated to be in 6 to 18 months, depending on browser implementation progress on other features in the same timeframe. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [eventsource] Moving Server-sent Events spec back to Last Call
On Sat, 12 Feb 2011, Arthur Barstow wrote: Regarding re-publishing the Server-sent Events spec [ED] as a new Last Call Working Draft ... 1. 11835 - EventSource must support cross-domain requests (ala CORS) http://www.w3.org/Bugs/Public/show_bug.cgi?id=11835 This will be supported once CORS is more widely deployed and understood by content developers. At a guess, 9 to 24 months. 2. 11836 - Don't specify the transport, just specify API and protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836 It's not clear to me what problem this bug describes, so I cannot currently give a timeline for its resolution. Discussion is ongoing. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
Thanks for all the feedbacks so far. Now that the thread became quieter, I hope we're getting agreed, at least on the basic concept. To make the points clearer, let me summarize what is being proposed (and what is not) with the quota API: - To have unified, shared quotas between different storage APIs, except for localStorage. (I'd include FileSystem API to the same group as other storage APIs.) - To have a common distinction between temporary and persistent storages across different storage APIs. - To have some sort of unified quota management system which can handle quota/usage query and request up front. It is not mandatory to guarantee the requested quota though, and UA can return a quota error whenever it sees the actual or logical storage limit is reached. As for the UI prompting, the proposing API specifies nothing about the timing or frequency with which the prompting should be made, except for a general guideline like: - For persistent storage UA should properly communicate with the user about how much disk space should be used, and must not silently discard the user data without the user's permission. I'm happy to hear more feedbacks if there are any. Thanks, Kinuko
Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)
Some other topics I have not (explicitly) responded yet:
On Thu, Feb 3, 2011 at 9:32 PM, João Eiras joao.ei...@gmail.com wrote:
interface StorageInfo {
Should probably be QuotaInfo or even QuotaManager ? Storage can and
will be confused with Web Storage.
I have no strong opinion here, while I mildly preferred 'StrongInfo'
as the API is meant to provide a common interface to various storage APIs.
Maybe QuotaInfo is better?
On Fri, Feb 4, 2011 at 5:37 AM, Eric Uhrhane er...@google.com wrote:
Hum, right. But then my comment does apply to requestQuota no ? No
need to ping data files to store a new value for the quota, which is
usually just a pref.
That's an implementation detail. Plus, storing a preference to a
persistent database involves file IO, which can take an arbitrarily
long time and/or fail.
An async API leaves a lot of freedom for developers, so in general we
try to use them for everything new outside the worker context.
As for sync vs async interfaces, I really would like to keep it
asynchronous. As Eric suggested UA may need some disk IO to return
the info or make a decision.
On Fri, Feb 4, 2011 at 5:52 AM, Jonas Sicking jo...@sicking.cc wrote:
One thing that you are not discussing is UA behavior when the quota
limit is reached. In Firefox 4, for IndexedDB, once the page reaches
50MB, we prompt the user if he/she wants to allow the page to store
more information. Only if the user chooses no do we start failing
writes. If the user chooses yes the fact that we reached the quota
limit is transparent to the page (apart from that a write takes a bit
longer while waiting for the prompt).
Technically we don't need to change anything about the spec to handle
this, we can just allow the UA to increase the quota limit at any
point in time if it desires. But I figured I should bring it up.
Thanks for bringing it up. Currently I do not intend to include
the UI prompting policies/issues or how UA should behave when the
quota limit is reached in the spec. And also (as I noted in my several
previous emails) I generally think that prompting to the user should
be avoided as much as possible, as far as the request from the
page does not impose major/visible pressure to the user disk.
On Fri, Feb 4, 2011 at 6:56 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Feb 3, 2011 at 7:32 AM, João Eiras joao.ei...@gmail.com wrote:
General note: using bytes as measure is probably overkill. While I
doubt localStorage would even exceed a couple megabytes, making an
entire e-mail account available offline with indexedDb or web sql db
could easily climb to a couple GBs. Perhaps kilobytes is better ?
Saying 4*1024*1024*1024 isn't a lot of work, and using different units means
I have to remember which units each function uses.
Using bytes might be overkill, but here I have a sympathy to Glenn's
opinion as I myself often get confused by different units in different APIs,
and I'd like to keep it to use bytes, the simplest units.
Thanks,
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 12:06 AM, Simon Pieters sim...@opera.com wrote: On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters sim...@opera.com wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org wrote: Just to confirm, we don't want the events to propagate to the window itself, right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request-transaction-database. This goes for both success and error events. However success doesn't bubble so normal event handlers doesn't fire on the transaction or database for success. But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For abort events the propagation path is just transaction-database since the target of abort events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an error event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing error handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. Hmm. I'm not sure what to think of IndexedDB using window.onerror. window.onerror is used for catching JS syntax errors and uncaught exceptions in scripts. Also, window.onerror is invoked directly without firing an actual event. Not just syntax errors. At least in firefox it also fires for uncaught exceptions. That's what I said. :-) Oops, my bad :-) So basically we fire all javascript errors which goes unhandled by the page (there is no way to handle syntax errors so they always goes unhandled). That is very much the case here, however since the error reporting must be asynchronous we report it using a event rather than an exception. What's the use case for firing an error event on window for IndexedDB? What is the use case for error events? I've always thought of it as a choke point where pages can catch JS errors and either display to the user or report back to the server for debugging. If that is the case then this is just another case where errors can arise. Do you have another use case in mind? There are lots of errors in the Web platform that are not reported to window.onerror: link style script img object video source track input ApplicationCache Worker SharedWorker EventSource WebSocket frame Should any of those also fire an event to window.onerror as their error event's default action? All of them? What I'm trying to do is to get some consistency so the Web platform doesn't appear so designed by committee where half the errors are reported to window.onerror and the other half not. It makes stuff harder to learn. In many of these cases other things than programming errors are likely the cause of the error. In most of what you are listing network errors are likely the most common source of errors. Note again that the IndexedDB errors we are talking about here are semantically very similar to exceptions. The only reason we're not making them exceptions is that we can't since exceptions would require synchronous IO. So I would argue that consistency with exceptions is more important that consistency with much of what you list above. That said, maybe we should fire window.onerror for many of the things that you list above. I'll repeat my question which you left unanswered: What is the use case for window.onerror that you had in mind which would require that we *don't* fire window.onerror for IndexedDB errors? / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking jo...@sicking.cc wrote: In many of these cases other things than programming errors are likely the cause of the error. In most of what you are listing network errors are likely the most common source of errors. Yeah. (I got the list by searching for named error in the spec, which matched a bunch of stuff that fires error events, but the list is very likely not exhaustive.) Note again that the IndexedDB errors we are talking about here are semantically very similar to exceptions. The only reason we're not making them exceptions is that we can't since exceptions would require synchronous IO. So I would argue that consistency with exceptions is more important that consistency with much of what you list above. OK. That said, maybe we should fire window.onerror for many of the things that you list above. Could you file a bug to that effect? I'll repeat my question which you left unanswered: What is the use case for window.onerror that you had in mind which would require that we *don't* fire window.onerror for IndexedDB errors? No use case for not doing it. I'm fine with doing it if there's a use case that warrants doing it, and we can keep the platform consistent with errors elsewhere. cheers -- Simon Pieters Opera Software
[Bug 12067] New: Improve error handling in workers
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067 Summary: Improve error handling in workers Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The error handling for workers is currently somewhat lacking. Consider a scenario when window A creates dedicated worker B which creates dedicated worker C. Currently if an error occurs in C, the following error handling occurs: 1. Fire error event on the global object for worker C. 2. Fire error event on the worker object associated with C. 3. Fire error event on the worker object associated with B. (and so on for each parent dedicated worker) 4. Report error to the user. If at any point an error is canceled (by calling event.preventDefault while the event is being fired), the steps are aborted an no new events are fired. There are two, related, problems here: First off window.onerror isn't involved. This generally works as a choke point to catch any programming errors, but currently doesn't catch errors in workers. Instead developers are required to add a event listener to every worker created and have that listener forward the errors to whatever code handles window.onerror. The second problem is that the same problem occurs within a worker. I.e. if a worker creates several workers, and want to catch all errors occurring within itself or its sub workers, it needs to both listen to globalscope.onerror as well as the error event on any and all workers it creates. To fix this, I suggest the following error propagation: 1. Fire error event on the global object for worker C. 2. Fire error event on the worker object associated with C. 3. Fire error event on the global object for worker B. 4. Fire error event on the worker object associated with B. (and so on for each parent dedicated worker) 5. Fire error event on window A. 6. Report error to the user. As before, if an error is cancelled, the steps are aborted and no further events are fired. This allows any worker to discover, and handle, programming errors within itself by simply listening to the error events on its scope. It also allows catching all unhandled programming errors in the context of a page by simply listening to window.onerror. This is what we have implemented in firefox for as long as we've had workers, so it's unlikely to break the world. For shared workers, the propagation should stop after firing the error event on the global object for the shared worker. This is similar to how error handling works on shared workers today. -- 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 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 12:41 PM, Simon Pieters sim...@opera.com wrote: On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking jo...@sicking.cc wrote: In many of these cases other things than programming errors are likely the cause of the error. In most of what you are listing network errors are likely the most common source of errors. Yeah. (I got the list by searching for named error in the spec, which matched a bunch of stuff that fires error events, but the list is very likely not exhaustive.) Note again that the IndexedDB errors we are talking about here are semantically very similar to exceptions. The only reason we're not making them exceptions is that we can't since exceptions would require synchronous IO. So I would argue that consistency with exceptions is more important that consistency with much of what you list above. OK. That said, maybe we should fire window.onerror for many of the things that you list above. Could you file a bug to that effect? I filed two bugs, one for workers in particular, and a general one for investigating making window.onerror more useful. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12068 I'll repeat my question which you left unanswered: What is the use case for window.onerror that you had in mind which would require that we *don't* fire window.onerror for IndexedDB errors? No use case for not doing it. I'm fine with doing it if there's a use case that warrants doing it, and we can keep the platform consistent with errors elsewhere. I think the usecase for window.onerror is a choke point for catching errors that arise in the page. At the very least programming errors. The choke point can be used to report back the error to the server as an error logging mechanism. It can possibly also be used for reporting errors directly to the user in the case the user is also the website author. However it seems like developer tools support that usecase better today. / Jonas
[Bug 11769] I have just implemented a 'javascript sandbox' using iframes and postMessage, exactly as intended by the specification. Thank you! It works beautifully! Safe XSS at last! Of course, now
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11769 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||LATER --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-02-15 00:34:55 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: This might make sense and should be considered, but before we add it we should wait for the sandboxing features we've already specified to be move widely implemented, so as to not get away from the implementations. -- 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.
[Bug 11770] test tx.executeSql(SELECT COUNT(*) FROM ToDo, [], function(result){}, function(tx, error){}); tx.executeSql(SELECT COUNT(*) FROM ToDo, [], function(result){}, function(tx, error){})
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11770 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||INVALID --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-02-15 00:41:32 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Could you elaborate? -- 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 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
wrote:
What's the current thinking in terms of events that we're firing? I
remember we talked about this a bit, but I don't remember the
conclusion and
I can't find it captured anywhere.
Here's a brain dump of the requirements as I remember them:
* Everything should have a source attribute.
* Everything done in the context of a transaction should have a
transaction
attribute. (Probably even errors, which I believe is not the current
case.)
* Only success events should have a result.
* Only error events should have a code and a messageor should they
just
have an error attribute which holds an IDBDatabaseError object? (If
it's
the former, then do we even need an interface for IDBDatabaseError to
be
defined?)
* IIRC, Jonas suggested at some point that maybe there should be
additional
attributes beyond just the source and/or objects should link to their
parents. (The latter probably makes the most sense, right? If so,
I'll bug
it.)
Is there anything I'm missing?
As far as I can tell, this means we need 5 events: an IDBEvent (with
source)
and then error with transaction, error without, success with, and
success
without. That seems kind of ugly though.
Another possibility is that we could put a transaction attribute on
IDBEvent
that's null when there's no transaction. And then error and success
would
have their own subclasses. To me, this sounds best.
Thoughts?
Actually, I was proposing something entirely different.
IDBRequest should look like this:
interface IDBRequest : EventTarget {
For each, what do we do when it's not available? Throw exception? Return
undefined? Null? Particularly in the errorCode case, it's not clear to me
what the right thing to do is.
How do IDBVersionChangeEvent and its version attribute fit in to this new
model? Should we add a nullable version attribute to IDBRequest and let the
function handling a blocked event check event.target.version? Could we add
a version attribute just to IDBVersionChangeRequest?
Adding a newVersion, nextVersion, or something similar to
IDBVersionChangeRequest seems like the best answer to me. Simply adding
version to it seems kind of confusing though.
J
attribute any result;
attribute unsigned long errorCode;
attribute DOMObject source;
attribute IDBTransaction transaction;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
attribute Function onsuccess;
attribute Function onerror;
};
success and error events are plain Event objects, i.e. no
indexedDB-specific properties.
The advantage of this is:
1. Request objects are actually useful as representing the request.
Consumers of a request can check what the readystate is and either get
the .result or attach a event listener as appropriate. (As things
stand now you can't really rely on .readyState. The only thing it
tells you is if you got to the request too late or not. If you risk
getting there too late you better rewrite your code)
2. Easier to implement a promises-style API on top of indexedDB.
3. More similar to for example XMLHttpRequest
The downside is:
1. Have to use a bigger syntax to get to the result. event.result
vs. event.target.result.
/ Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
wrote:
What's the current thinking in terms of events that we're firing? I
remember we talked about this a bit, but I don't remember the
conclusion and
I can't find it captured anywhere.
Here's a brain dump of the requirements as I remember them:
* Everything should have a source attribute.
* Everything done in the context of a transaction should have a
transaction
attribute. (Probably even errors, which I believe is not the current
case.)
* Only success events should have a result.
* Only error events should have a code and a messageor should they
just
have an error attribute which holds an IDBDatabaseError object? (If
it's
the former, then do we even need an interface for IDBDatabaseError to
be
defined?)
* IIRC, Jonas suggested at some point that maybe there should be
additional
attributes beyond just the source and/or objects should link to their
parents. (The latter probably makes the most sense, right? If so,
I'll bug
it.)
Is there anything I'm missing?
As far as I can tell, this means we need 5 events: an IDBEvent (with
source)
and then error with transaction, error without, success with, and
success
without. That seems kind of ugly though.
Another possibility is that we could put a transaction attribute on
IDBEvent
that's null when there's no transaction. And then error and success
would
have their own subclasses. To me, this sounds best.
Thoughts?
Actually, I was proposing something entirely different.
IDBRequest should look like this:
interface IDBRequest : EventTarget {
For each, what do we do when it's not available? Throw exception?
Return undefined? Null? Particularly in the errorCode case, it's not
clear to me what the right thing to do is.
How do IDBVersionChangeEvent and its version attribute fit in to this new
model? Should we add a nullable version attribute to IDBRequest and let the
function handling a blocked event check event.target.version? Could we add
a version attribute just to IDBVersionChangeRequest?
Adding a newVersion, nextVersion, or something similar to
IDBVersionChangeRequest seems like the best answer to me. Simply adding
version to it seems kind of confusing though.
Adding it to the request won't help as the versionchange event is
fired at other databases, not at the request. Adding it to the request
is also not needed since the new version isn't something that is the
result of the request, it's something you specify when creating the
request.
I think we can leave IDBVersionChangeEvent as it is, it's an entirely
different beast from success/error.
/ Jonas
RE: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Sunday, February 06, 2011 12:43 PM On Tue, Dec 14, 2010 at 4:26 PM, Pablo Castro pablo.cas...@microsoft.com wrote: From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Tuesday, December 14, 2010 4:23 PM On Wed, Dec 15, 2010 at 12:19 AM, Pablo Castro pablo.cas...@microsoft.com wrote: 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. Yeah, that's a good point for this case, avoiding data-dependent errors is probably worth the perf hit. My current thinking is that we should have some relatively large limitmaybe on the order of 64k? It seems like it'd be very difficult to hit such a limit with any sort of legitimate use case, and the chances of some subtle data-dependent error would be much less. But a 1GB key is just not going to work well in any implementation (if it doesn't simply oom the process!). So despite what I said earlier, I guess I think we should have some limit...but keep it an order of magnitude or two larger than what we expect any legitimate usage to hit just to keep the system as flexible as possible. Does that sound reasonable to people? I thought we were trying to avoid data-dependent errors and thus shooting for having no limit (which may translate into having very large limits in actual implementations but not the kind of thing you'd typically hit). Specifying an exact size may be a bit weird...I guess an alternative could be to spec what is the minimum size UAs need to support. A related problem is what units is this specified in, if it's bytes then that means developers need to make assumptions about how strings are stored or something. -pablo
RE: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
(sorry for my random out-of-timing previous email on this thread. please see below for an actually up to date reply) -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Monday, February 07, 2011 3:31 PM On Mon, Feb 7, 2011 at 3:07 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 2:49 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Feb 6, 2011 at 11:41 PM, Jeremy Orlow jor...@chromium.org wrote: On Sun, Feb 6, 2011 at 11:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Feb 6, 2011 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: On Sun, Feb 6, 2011 at 2:03 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 2/6/2011 12:42 PM, Jeremy Orlow wrote: My current thinking is that we should have some relatively large limitmaybe on the order of 64k? It seems like it'd be very difficult to hit such a limit with any sort of legitimate use case, and the chances of some subtle data-dependent error would be much less. But a 1GB key is just not going to work well in any implementation (if it doesn't simply oom the process!). So despite what I said earlier, I guess I think we should have some limit...but keep it an order of magnitude or two larger than what we expect any legitimate usage to hit just to keep the system as flexible as possible. Does that sound reasonable to people? Are we thinking about making this a MUST requirement, or a SHOULD? I'm hesitant to spec an exact size as a MUST given how technology has a way of changing in unexpected ways that makes old constraints obsolete. But then, I may just be overly concerned about this too. If we put a limit, it'd be a MUST for sure. Otherwise people would develop against one of the implementations that don't place a limit and then their app would break on the others. The reason that I suggested 64K is that it seems outrageously big for the data types that we're looking at. But it's too small to do much with base64 encoding binary blobs into it or anything else like that that I could see becoming rather large. So it seems like a limit that'd avoid major abuses (where someone is probably approaching the problem wrong) but would not come close to limiting any practical use I can imagine. With our architecture in Chrome, we will probably need to have some limit. We haven't decided what that is yet, but since I remember others saying similar things when we talked about this at TPAC, it seems like it might be best to standardize it--even though it does feel a bit dirty. One problem with putting a limit is that it basically forces implementations to use a specific encoding, or pay a hefty price. For example if we choose a 64K limit, is that of UTF8 data or of UTF16 data? If it is of UTF8 data, and the implementation uses something else to store the date, you risk having to convert the data just to measure the size. Possibly this would be different if we measured size using UTF16 as javascript more or less enforces that the source string is UTF16 which means that you can measure utf16 size on the cheap, even if the stored data uses a different format. That's a very good point. What's your suggestion then? Spec unlimited storage and have non-normative text saying that most implementations will likely have some limit? Maybe we can at least spec a minimum limit in terms of a particular character encoding? (Implementations could translate this into the worst case size for their own native encoding and then ensure their limit is higher.) I'm fine with relying on UTF16 encoding size and specifying a 64K limit. Like Shawn points out, this API is fairly geared towards JavaScript anyway (and I personally don't think that's a bad thing). One thing that I just thought of is that even if implementations use other encodings, you can in the vast majority of cases do a worst-case estimate and easily see that the key that is used is below 64K. That said, does having a 64K limit really help anyone? In SQLite we can easily store vastly more than that, enough that we don't have to specify a limit. And my understanding is that in the Microsoft implementation, the limits for what they can store without resorting to various tricks, is much lower. So since that implementation will have to implement special handling of long keys anyway, is there a difference between saying a 64K limit vs. saying unlimited? As I explained earlier: The reason that I suggested 64K is that it seems outrageously big for the data types that we're looking at. But it's too small to do much with base64 encoding binary blobs into it or anything else like that that I could see becoming rather large. So it seems like a limit that'd avoid major abuses (where someone is probably approaching
