Re: [IndexedDB] .value of no-duplicate cursors
On Wed, Jun 30, 2010 at 10:42 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jul 1, 2010 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
This was one issue we ran into while implementing IndexedDB. In the
code examples I'll use the mozilla proposed asynchronous APIs, but the
issue applies equally to the spec as it is now, as well as the
synchronous APIs.
Consider an objectStore containing the following objects:
{ id: 1, name: foo, flags: [hi, low] }
{ id: 2, name: foo, flags: [apple, orange] }
{ id: 3, name: foo, flags: [hello, world] }
{ id: 4, name: bar, flags: [fahrvergnügen] }
And an index keyed on the name property. What should the following code
alert?
results = [];
db.objectStore(myObjectStore).index(nameIndex).openCursor(null,
IDBCursor.NEXT_NO_DUPLICATE).onsuccess = function(e) {
cursor = e.result;
if (!cursor) {
alert(results.length);
alert(results);
}
results.push(cursor.value);
cursor.continue();
};
It's clear that the first alert would display '2', as there are 2
distinct 'name' values in the objectStore. However it's not clear what
the second alert would show. I.e. what would cursor.value be on each
'success' event firing?
We could define that it is one of the rows matching the distinct
value. In that case either 1,4, 2,4 or 3,4 would be valid values
for the second alert. If we choose that solution then ideally we
should define which one and make it consistent in all implementations.
Alternatively we could say that .value is null for all *_NO_DUPLICATE
cursors.
The question equally applies if the above code used openObjectCursor
rather than openCursor. However if we define that .value is null for
*_NO_DUPLICATE cursors, then openObjectCursor with *_NO_DUPLICATE
doesn't make much sense in that it returns the same thing as
openCursor with *_NO_DUPLICATE.
I don't personally don't care much which solution we use. I'm unclear
on what the exact use cases are for *_NO_DUPLICATE cursors.
This is a very good point. What are the use cases? After all, you can
easily emulate such a cursor yourself. Unless there are some compelling use
cases, I'd be happy to just get rid of it.
Same here. Though I suspect there are use cases as SQL has a similar
feature (SELECT DISTINCT).
However if
we do say that .value should represent a particular row, then I think
we should define which row is returned.
Agreed that it should be deterministic. I'm fine with null, the first
value, or the last value. If we do null, then I think calling
openObjectCursor with *_NO_DUPLICATE should be an error.
Agreed. We just have to define what first and/or last means. Two
alternatives are insertion order or order in objectStore. I prefer the
latter as to avoid introducing insertion order as a concept.
Hmm.. come to think of it, we likely have to define an order anyway.
So that it is deterministic what the order of the example index is
defined when iterated with a normal cursor. I filed a bug on getting
that defiend:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10058
/ Jonas
Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?
On Wed, Jun 30, 2010 at 8:16 PM, Jeremy Orlow jor...@chromium.org wrote: I've thought about this more and have some additional doubts inline. On Thu, Jul 1, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, Currently the IndexedDB specification is silent on what should happen if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove, IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY transaction. There are two possible ways we can handle this: 1. We can throw an exception. 2. We can return a IDBRequest object and asynchronously fire a 'error' event on this object. The advantage of 1 is that we pretty much know that this was an error due to a bug in the web page, I don't see why this is compelling. Many of the other errors that you still propose we fire via the callback are due to bugs in the page. and we can always know this synchronously without having to consult the database. So? Just because we can doesn't mean we should. Throwing an error means that all the existing infrastructure for error handling with automatically kick in. For example any higher-level try/catch constructs will have an opportunity to catch the error. Implementations generally report uncaught exceptions to an error log. The browser will fire an 'error' event on the window which the page can use for further logging. Firing an error event on the other hand does not allow the browser to automatically log the error in a console as the page hasn't yet gotten a chance to handle it. Sure, but this doesn't help the majority of error conditions in IndexedDB. It also ignores the cost of handling errors in 2 different ways. I'm arguing that people generally won't want to check for all types of errors, such as writing in a READ_ONLY transaction. Compare to the Node.appendChild function which throws for a number of conditions, yet I've never seen anyone put a try around it and check for HIERARCHY_REQUEST_ERR. Additionally, anything you do can likely in theory throw exceptions. For example if you specify the wrong number of arguments or call a function that doesn't exist, this will result in an exception. However you rarely see people wrap try around calls to try to handle this type of bugs. Another example is the line: db.objectStore(myObjectStore).get(53) can result in errors both being thrown and being reported as an error event. If the objectStore myObjectStore doesn't exist, then the .objectStore() call will return null and the js engine will throw due to trying to call a function on a null value. Error checking is mostly useful when there are ways you can actually handle the error. I think generally if someone calls .put during a READ_ONLY transaction, they simply have a bug in their program and there is little they can do in terms of handling that, short of simply logging it. The advantage of 2 is that this is consistent with other error conditions, such as writing duplicate keys, disk errors during writing the database to disk, internal errors in the database, etc. The other problem is that users then need 2 sets of error handling routines for each call. Given how difficult it is to get web developers to do any error checking, requiring 2 types of checks seems like a big downside. Actually, this is somewhat faulty math. With exceptions you can put a try/catch high up in a call stack to catch errors from multiple different locations. This will catch all errors thrown from all function calls inside the try. Compare that to error events, which has to be manually installed at every single request site. From this point of view, the more errors we move to being reported as exceptions, the more easily we're making it for developers to catch more errors. Javascript has a error reporting mechanism, exceptions. We should try to make good use of it. While consistency, and only needing to check for errors one way, is certainly good arguments, I would argue that people won't need to check for calling-add-on-read-only-transactions. For properly written code it's not an error that will occur, and thus there is no need to check for it. In fact, you probably are generally better off letting the exception bubble all the way up and get logged or caught by generic error handlers. These are awfully bold assumptions. Simply not catching the error is not an option for many web applications or libraries. At very least, they'll need to add finally statements to handle such cases. How would one handle the case of .put being called on a READ_ONLY transaction? Additionally, the structured clone algorithm, which defines that an exception should synchronously be thrown if the object is malformed, for example if it consists of a cyclic graph. So .add/.put/.update can
[widgets] Draft references in Digital Signature for Widgets spec
Re normative references to draft specs in the Digital Signature for Widgets (DS4W) spec, when I asked Frederick for his best guestimate when the XML Security WG's draft references would reach CR, he reported: [[ Tentatively, as documented on our roadmap page:http://www.w3.org/2008/xmlsec/wiki/Roadmap CR Fall 2010 • XML Signature 1.1 • XML Signature Properties • XML Encryption 1.1 • XML Security Generic Hybrid Ciphers XML Security Algorithm Cross Reference is intended to be a note, so I don't expect it to go to CR. The normative definitions are in the other documents it references. Of course it is possible the CR date might change if a significant issue is raised, but I don't expect that to happen for Signature or Signature Properties. ]] Since the Cross Reference spec's final publication is a non-normative document (Working Group Note), perhaps it should become an Informative reference. -Art Barstow On 6/30/10 7:04 AM, Barstow Art (Nokia-CIC/Boston) wrote: 4. Dependencies on draft specs and progressing to PR Draft dependencies: http://lists.w3.org/Archives/Public/www-archive/2010Jun/0073.html PR process: http://lists.w3.org/Archives/Public/www-archive/2010Jun/0075.html
[widgets] Draft minutes from 1 July 2010 voice conf
The draft minutes from the July 1 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/07/01-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before July 8 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Steven Pemberton, for Art Barstow - DRAFT - Widgets Voice Conference 01 Jul 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1226.html See also: [3]IRC log [3] http://www.w3.org/2010/07/01-wam-irc Attendees Present Art, StevenP, Josh, Marcos, Frederick Regrets Frederick Chair Art, Steven Scribe Art, Steven, Steven Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Packaging and Configuration spec and Issue-117 3. [7]TWI spec and Issue-116 4. [8]Dependencies on draft specs and publishing PRs 5. [9]AOB * [10]Summary of Action Items _ ArtB Scribe: Art, Steven ArtB ScribeNick: ArtB Marcos woops Review and tweak agenda AB: draft agenda was sent to the list yesterday [11]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1 226.html. We will include Marcos' proposal for Issue-116 when discussing TWI spec and move Announcements to AOB. Any other change requests? [11] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1226.html%3E. Packaging and Configuration spec and Issue-117 AB: Issue-117 [12]http://www.w3.org/2008/webapps/track/issues/117 In Widget PC Spec, need to clarify in the spec that dir attribute does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir attribute only affects human readable strings. ... Marcos' proposed resolution is captured in [13]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1 211.html ... I have two questions: are these clarifications really needed and is the proposed solution purely editorial? [12] http://www.w3.org/2008/webapps/track/issues/117%3E [13] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1211.html%3E MC: they are editorial ... if implemented without this proposal, the problem would be obvious ... and the proposed resolution would not affect an implementation ... think the spec is clear direction would not affect data like URIs ... I do think, however, it would be good to clarify the spec ... think e-mail needs to be considered ... i.e. if it is a displayable string or a keyword JS: by email do you mean content or the email address? MC: the spec just says it is a string ... could make it as a keyword and thus dir doesn't apply AB: think we need to give people to respond to this proposed resolution ... it was only proposed two days ago SP: should we ask the I18N WG? MC: yes, good idea ... wanted to first get feedback from WebApps ... if there is agreement there, we can then ask I18N WG to review scribe ACTION: Marcos submit proposed resolution to Issue-117 to I18N for comments [recorded in [14]http://www.w3.org/2010/07/01-wam-minutes.html#action01] trackbot Created ACTION-563 - Submit proposed resolution to Issue-117 to I18N for comments [on Marcos Caceres - due 2010-07-08]. timeless I'm fine with the proposed resolution AB: we also need to make sure people in WebApps have a chance to comment on MC's proposal TWI spec and Issue-116 AB: yesterday Marcos submitted a proposal [15]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1 229.html to address Issue-116 [16]http://www.w3.org/2008/webapps/track/issues/116 ... the previous plan of record was to address this issue Need to flesh out the security considerations for the openURL method in the Widget Interface spec by creating non-normative guidelines. This new proposal would remove the openURL method from the spec. ... this proposed resolution is also quite new so the WG hasn't had much of a chance to reply [15] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1229.html%3E [16] http://www.w3.org/2008/webapps/track/issues/116%3E MC: I still need to get feedback from Opera people ... so far I haven't received any comments ... I personally think it should be dropped ... think it can do more harm than good ... and that it isn't really needed JS: I agree with removing this feature ... I don't think we need it AB: want the WG to have at least a week to submit comments ... I presume that if this method is removed, we need to drop back to LCWD ... Agreed? MC: yes AB: we already have 2 impls that pass our test
Re: [File API] Recent Updates To Specification + Co-Editor
+1 to window.createBlobUrl(blob) and window.revokeBlobUrl(url) , they make lifetime of a blob url (which is different from lifetime of the Blob JS object) way more clear to me, since it attaches it explicitly to a window, and to a specific window in that. Multi-window web apps (like GMail or IM) have multiple windows that cross-script each other, so it's very easy to change the code a little and the 'spawning Document, as defined in the spec now, changes, since it's implicitly captured. Explicit is good. It also indeed makes it possible for a good-behaving app to prevent a memory leak in long-lived pages and potentially shared workers, since it gives an explicit 'revoke' method. Nice idea, lets see if it can be added to the spec. Dmitry On Wed, Jun 30, 2010 at 5:38 PM, Jian Li jia...@chromium.org wrote: Thanks for the update. We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.comwrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed
Re: [File API] Recent Updates To Specification + Co-Editor
On Thu, Jul 1, 2010 at 11:47 AM, Dmitry Titov dim...@chromium.org wrote: +1 to window.createBlobUrl(blob) and window.revokeBlobUrl(url) +1 too, presumably these would also be available workers, particularly shared workers. , they make lifetime of a blob url (which is different from lifetime of the Blob JS object) way more clear to me, since it attaches it explicitly to a window, and to a specific window in that. Multi-window web apps (like GMail or IM) have multiple windows that cross-script each other, so it's very easy to change the code a little and the 'spawning Document, as defined in the spec now, changes, since it's implicitly captured. Explicit is good. By factoring the .url property out, the Blob object itself acts much more like a String primitive in that it's an immutable container for data that can be passed freely throughout a graph of connected browsing contexts, and potentially serialized and sent via PostMessage. Overall simpler to grok w/o the 'spawning context' concept. It also indeed makes it possible for a good-behaving app to prevent a memory leak in long-lived pages and potentially shared workers, since it gives an explicit 'revoke' method. Nice idea, lets see if it can be added to the spec. Dmitry On Wed, Jun 30, 2010 at 5:38 PM, Jian Li jia...@chromium.org wrote: Thanks for the update. We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.comwrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an
Re: LCWD comments
On Wed, Jun 30, 2010 at 7:08 PM, Krzysztof Maczyński 198...@gmail.comwrote:
11. In [c]:
there is no way to override the type. It's always assumed to be
JavaScript.
This is a violation of orthogonality for no real benefit.
I know that the NativeClient team has experimented with supporting native
code in workers (in Chrome) in the past, using some fairly ugly hack based
on the suffix of the URL. Having some support for MIME types would enable
something like this in the future without having to resort to those hacks.
12. In [c]:
If there are any outstanding transactions that have callbacks
What's a transaction, when has it got a callback?
I believe this refers to DB APIs (WebSQLDatabase, IndexedDB [
http://www.w3.org/TR/IndexedDB/]) that might be exposed to workers.
Thus, scripts must be external files with the same scheme as the original
page: you can't load a script from a data: URL
Why impose this restriction? Is it that exceptions to same-origin policy
when it's still new would be confusing for specifiers and the audience, so
this possibility is postponed to the next version? In any case, I suggest
allowing workers to be instantiated with Function objects (whatever this may
be in language bindings, given positive resolution of 11) as well. Including
workers directly inline seems natural in many scenarios.
Agreed that data URLs would be useful. My recollection is that they are
currently prohibited because the script URL is used to derive the security
context for that worker (rather than inheriting it from the parent) which
I've never entirely understood.
I don't see how we can expose Function objects since the execution context
of workers are distinct from the execution context of the main page.
For example:
my_global = 123;
function worker_script() {
do_something(my_global);
}
new Worker(worker_script);
What does worker_script do when it accesses my_global? It certainly can't
have the global scope of the parent page in its scope chain. There's a
slightly longer discussion of that topic here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024576.html
Re: [IndexedDB] .value of no-duplicate cursors
Replying to get Ben's email to the list as his address seems to be
stuck in moderation...
On Thu, Jul 1, 2010 at 1:37 PM, ben turner b...@mozilla.com wrote:
I think I would be happy just removing the _NO_DUPLICATE directions.
As Jeremy noted it is quite easy to emulate and it would then be up to
the webapp author whether she wanted the first or last duplicate
value.
-Ben
On Wed, Jun 30, 2010 at 11:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 30, 2010 at 10:42 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jul 1, 2010 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
This was one issue we ran into while implementing IndexedDB. In the
code examples I'll use the mozilla proposed asynchronous APIs, but the
issue applies equally to the spec as it is now, as well as the
synchronous APIs.
Consider an objectStore containing the following objects:
{ id: 1, name: foo, flags: [hi, low] }
{ id: 2, name: foo, flags: [apple, orange] }
{ id: 3, name: foo, flags: [hello, world] }
{ id: 4, name: bar, flags: [fahrvergnügen] }
And an index keyed on the name property. What should the following code
alert?
results = [];
db.objectStore(myObjectStore).index(nameIndex).openCursor(null,
IDBCursor.NEXT_NO_DUPLICATE).onsuccess = function(e) {
cursor = e.result;
if (!cursor) {
alert(results.length);
alert(results);
}
results.push(cursor.value);
cursor.continue();
};
It's clear that the first alert would display '2', as there are 2
distinct 'name' values in the objectStore. However it's not clear what
the second alert would show. I.e. what would cursor.value be on each
'success' event firing?
We could define that it is one of the rows matching the distinct
value. In that case either 1,4, 2,4 or 3,4 would be valid values
for the second alert. If we choose that solution then ideally we
should define which one and make it consistent in all implementations.
Alternatively we could say that .value is null for all *_NO_DUPLICATE
cursors.
The question equally applies if the above code used openObjectCursor
rather than openCursor. However if we define that .value is null for
*_NO_DUPLICATE cursors, then openObjectCursor with *_NO_DUPLICATE
doesn't make much sense in that it returns the same thing as
openCursor with *_NO_DUPLICATE.
I don't personally don't care much which solution we use. I'm unclear
on what the exact use cases are for *_NO_DUPLICATE cursors.
This is a very good point. What are the use cases? After all, you can
easily emulate such a cursor yourself. Unless there are some compelling use
cases, I'd be happy to just get rid of it.
Same here. Though I suspect there are use cases as SQL has a similar
feature (SELECT DISTINCT).
However if
we do say that .value should represent a particular row, then I think
we should define which row is returned.
Agreed that it should be deterministic. I'm fine with null, the first
value, or the last value. If we do null, then I think calling
openObjectCursor with *_NO_DUPLICATE should be an error.
Agreed. We just have to define what first and/or last means. Two
alternatives are insertion order or order in objectStore. I prefer the
latter as to avoid introducing insertion order as a concept.
Hmm.. come to think of it, we likely have to define an order anyway.
So that it is deterministic what the order of the example index is
defined when iterated with a normal cursor. I filed a bug on getting
that defiend:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10058
/ Jonas
Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?
Replying to get Ben's email to the list as it seems to be stuck in moderation... On Thu, Jul 1, 2010 at 1:38 PM, ben turner b...@mozilla.com wrote: I would also point out that throwing exceptions at the call site makes debugging much easier in my opinion. Our error events currently don't include information like filename and line number where the failing request was generated (though I think we should add that eventually). Exceptions are much easier to track down, diagnose, and fix. -Ben On Thu, Jul 1, 2010 at 2:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 30, 2010 at 8:16 PM, Jeremy Orlow jor...@chromium.org wrote: I've thought about this more and have some additional doubts inline. On Thu, Jul 1, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, Currently the IndexedDB specification is silent on what should happen if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove, IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY transaction. There are two possible ways we can handle this: 1. We can throw an exception. 2. We can return a IDBRequest object and asynchronously fire a 'error' event on this object. The advantage of 1 is that we pretty much know that this was an error due to a bug in the web page, I don't see why this is compelling. Many of the other errors that you still propose we fire via the callback are due to bugs in the page. and we can always know this synchronously without having to consult the database. So? Just because we can doesn't mean we should. Throwing an error means that all the existing infrastructure for error handling with automatically kick in. For example any higher-level try/catch constructs will have an opportunity to catch the error. Implementations generally report uncaught exceptions to an error log. The browser will fire an 'error' event on the window which the page can use for further logging. Firing an error event on the other hand does not allow the browser to automatically log the error in a console as the page hasn't yet gotten a chance to handle it. Sure, but this doesn't help the majority of error conditions in IndexedDB. It also ignores the cost of handling errors in 2 different ways. I'm arguing that people generally won't want to check for all types of errors, such as writing in a READ_ONLY transaction. Compare to the Node.appendChild function which throws for a number of conditions, yet I've never seen anyone put a try around it and check for HIERARCHY_REQUEST_ERR. Additionally, anything you do can likely in theory throw exceptions. For example if you specify the wrong number of arguments or call a function that doesn't exist, this will result in an exception. However you rarely see people wrap try around calls to try to handle this type of bugs. Another example is the line: db.objectStore(myObjectStore).get(53) can result in errors both being thrown and being reported as an error event. If the objectStore myObjectStore doesn't exist, then the .objectStore() call will return null and the js engine will throw due to trying to call a function on a null value. Error checking is mostly useful when there are ways you can actually handle the error. I think generally if someone calls .put during a READ_ONLY transaction, they simply have a bug in their program and there is little they can do in terms of handling that, short of simply logging it. The advantage of 2 is that this is consistent with other error conditions, such as writing duplicate keys, disk errors during writing the database to disk, internal errors in the database, etc. The other problem is that users then need 2 sets of error handling routines for each call. Given how difficult it is to get web developers to do any error checking, requiring 2 types of checks seems like a big downside. Actually, this is somewhat faulty math. With exceptions you can put a try/catch high up in a call stack to catch errors from multiple different locations. This will catch all errors thrown from all function calls inside the try. Compare that to error events, which has to be manually installed at every single request site. From this point of view, the more errors we move to being reported as exceptions, the more easily we're making it for developers to catch more errors. Javascript has a error reporting mechanism, exceptions. We should try to make good use of it. While consistency, and only needing to check for errors one way, is certainly good arguments, I would argue that people won't need to check for calling-add-on-read-only-transactions. For properly written code it's not an error that will occur, and thus there is no need to check for it. In fact, you probably are generally better off
Re: LCWD comments
2010/7/1 Drew Wilson atwil...@google.com: On Wed, Jun 30, 2010 at 7:08 PM, Krzysztof Maczyński 198...@gmail.com wrote: 11. In [c]: there is no way to override the type. It's always assumed to be JavaScript. This is a violation of orthogonality for no real benefit. There is *a lot* of scripts out there. However browsers have never have enforced a mimetype check for script loads, which has resulted in great many (probably the majority) of these scripts are not server with a mimetype declaring them to be javascript. As a result of this, the benefit of ignoring the mimetype is that we can access the vast body of scripts available on the web. / Jonas
How to get a FileWriter/BlobWriter/BlobSaver
The biggest unknown in the current BlobWriter spec [1] is how you
obtain one in the first place.
There are two current proposals, which I've summarized below. I've
heard only a few voices on this topic, and would love to get more
opinions. New proposals would be welcome as well.
If you favor one of the below, and don't think I've done it justice,
please do weigh in with further details.
Proposal A: a new input control.
You'd add markup such as input type=saveas or button type=saveas.
It could be styled however you please; it would pop up a standard
File-SaveAs dialog, so there's no security problem there. You'd
handle the event when the user selects a save location in order to
grab the BlobWriter.
Pluses:
It parallels input type=file.
It's user-initiated, so the default flow doesn't ever surprise the
user with a popup.
Proposal B: a new method on Window.
window.saveAs(function(blobWriter) { /* grab the writer and use it
*/}, function(error) {...});
Pluses:
It's a simple async API like many others we provide.
App developers are free to provide any UI or control flow they like.
In either case, we could add a parameter for the Blob, so that the
system knows what it's saving, and/or a suggested mime-type and base
name. Adding the Blob itself would let us eliminate the
writeFile()/save() call mentioned in [2], so that you'd only grab the
returned BlobWriter if you wanted to handle the progress events.
Eric
[1] http://dev.w3.org/2009/dap/file-system/file-writer.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1223.html
Re: BlobWriter simplification/split
On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com wrote: Following up on discussions mainly at [1] and use cases at [2], I'd like to propose splitting the BlobWriter [née FileWriter] class, with an eye to solving some UI problems and simplifying implementation. When saving a Blob to a location outside the FileSystem API sandbox, we want to prompt the user exactly once, and want to be able to indicate that a write is taking place, e.g. by throbbing the download indicator. We want the throbbing to go away as soon as the write is done, and we don't want the app to have continued privileges to write outside the sandbox. [That's been debated, but I think it's beyond the scope of what we're working on so far, so let's leave that case for later expansion.] When writing inside the sandbox, we probably don't need the throbber at all, and we definitely don't want to prompt the user on each write. Leaving aside the question of how one obtains a BlobWriter without using the sandbox and when exactly prompts happen [I'll open another thread for that], I think that: * We don't want to have the same API call cause prompts to pop up on some instances of BlobWriter and not others. * We don't want to have the same API call be reusable on some instances of BlobWriter and not others. I propose the following split: Define a parent class, SimpleBlobWriter, that's used for one-shot Blob export. This is what you use when you don't have the FileSystem API, when the user selects the save location. It contains a writeFile() method, which writes a Blob to a file in a single operation. It is an error to call writeFile if readyState is not INIT, so SimpleBlobWriter is single-use. Its other members are abort(), readyState, the ready state constants, error, length, and the progress event handlers, as defined in the current spec. Derive from SimpleBlobWriter the class BlobWriter, which adds position, truncate(), seek(), and write(), as defined in the current spec. This is what the FileSystem API's createWriter() call would return. This lets you have different APIs for different behaviors, and removes fields from SimpleBlobWriter that aren't actually useful without the FileSystem API. How does that sound? Sounds great! Actually, i realized that I have second thoughts on some details here. It would be great if the save as functionality provided by the SimpleBlobWriter worked such that at the time the where do you want to save a file dialog pops up, the UA already knows what Blob is going to be saved. This has several advantages over the UA first receiving a request to save something, and then receiving the data that is to be saved. For example: * If the Blob is a File, default the filename to File.name * Allows the UA to display the size of the file, thus allowing the user to save to different locations depending on the expected size of the file * Allows the UA to determine the type of the Blob and adjust the filename based on that. Firefox does this for content-disposition save-as dialogs. As a separate question, at what URL are the latest drafts available? Is http://dev.w3.org/2009/dap/file-system/file-writer.html still authoritative? / Jonas
Re: BlobWriter simplification/split
On Thu, Jul 1, 2010 at 4:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com wrote: Following up on discussions mainly at [1] and use cases at [2], I'd like to propose splitting the BlobWriter [née FileWriter] class, with an eye to solving some UI problems and simplifying implementation. When saving a Blob to a location outside the FileSystem API sandbox, we want to prompt the user exactly once, and want to be able to indicate that a write is taking place, e.g. by throbbing the download indicator. We want the throbbing to go away as soon as the write is done, and we don't want the app to have continued privileges to write outside the sandbox. [That's been debated, but I think it's beyond the scope of what we're working on so far, so let's leave that case for later expansion.] When writing inside the sandbox, we probably don't need the throbber at all, and we definitely don't want to prompt the user on each write. Leaving aside the question of how one obtains a BlobWriter without using the sandbox and when exactly prompts happen [I'll open another thread for that], I think that: * We don't want to have the same API call cause prompts to pop up on some instances of BlobWriter and not others. * We don't want to have the same API call be reusable on some instances of BlobWriter and not others. I propose the following split: Define a parent class, SimpleBlobWriter, that's used for one-shot Blob export. This is what you use when you don't have the FileSystem API, when the user selects the save location. It contains a writeFile() method, which writes a Blob to a file in a single operation. It is an error to call writeFile if readyState is not INIT, so SimpleBlobWriter is single-use. Its other members are abort(), readyState, the ready state constants, error, length, and the progress event handlers, as defined in the current spec. Derive from SimpleBlobWriter the class BlobWriter, which adds position, truncate(), seek(), and write(), as defined in the current spec. This is what the FileSystem API's createWriter() call would return. This lets you have different APIs for different behaviors, and removes fields from SimpleBlobWriter that aren't actually useful without the FileSystem API. How does that sound? Sounds great! Actually, i realized that I have second thoughts on some details here. It would be great if the save as functionality provided by the SimpleBlobWriter worked such that at the time the where do you want to save a file dialog pops up, the UA already knows what Blob is going to be saved. This has several advantages over the UA first receiving a request to save something, and then receiving the data that is to be saved. For example: * If the Blob is a File, default the filename to File.name * Allows the UA to display the size of the file, thus allowing the user to save to different locations depending on the expected size of the file * Allows the UA to determine the type of the Blob and adjust the filename based on that. Firefox does this for content-disposition save-as dialogs. Yeah,take a look at [1] as well; this could eliminate the need for the save/writeFile call on the simpler interface. As a separate question, at what URL are the latest drafts available? Is http://dev.w3.org/2009/dap/file-system/file-writer.html still authoritative? Yes, I haven't moved or renamed it, though the path and name are now both obsolete. That's probably worth doing as of WebApps publishing an official draft of it. Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0023.html
Re: [File API] Recent Updates To Specification + Co-Editor
One more question. Should we also rename FileError to BlobError and FileException to BlobException in order to be consistent with the naming changes? Thanks, Jian On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of the File API specification. Most people who work on HTML5 and WebApps know Jonas' contributions to both WGs; with everyone's consent, I'd like to nominate him as co-editor. His model for an asynchronous event-driven API is what prompted the initial rewrite, and he also works on both File API and IndexedDB implementation (amongst other things). -- A* [1] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
