Re: [widgets PC] i18n comment 22: Default content
On Fri, May 28, 2010 at 8:40 AM, Richard Ishida ish...@w3.org wrote: Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 22 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: 8.4 http://www.w3.org/TR/2009/WD-widgets-20090528/#other-attributes Comment: There is an example of the empty language tag with the comment The user agents will treat this as unlocalized content. This should be user agent singular. More importantly, there should be a distinction between unlocalized and non-linguistic or undetermined or at least default content (which is what you mean). Note that the tag und represents text whose language cannot be determined. I would suggest default content here (and elsewhere). Fixed. Used default content globally. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [widgets PC] i18n comment 21: i18n string
On Fri, May 28, 2010 at 8:38 AM, Richard Ishida ish...@w3.org wrote: Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 21 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: General Comment: Language tags are presented as lowercase. While case has no meaning in language tags, they are typically canonicalized (and are recommended to use) the case conventions in BCP 47. See http://tools.ietf.org/html/bcp47#section-2.1.1 That is no problem for when language tags appear in xml:lang, as they are cononicalized to lower-case. However, following BCP 47 would cause issues with matching folders, as they are treated as case sensitive. In the Folder-based localization section, I've added the following to the authoring guidelines: Because folders inside a widget package are treated by the user agent as case sensitive, the names of the folders inside a locale folder need to be in lower-case. Unfortunately, this violates the case conventions recommended in BCP 47. In the The xml:lang Attribute section of the spec, I've added the following to the authoring guidelines: Please note that, while case has no meaning in language tags, it is recommend that with xml:lang authors use the case conventions recommended in BCP 47. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
RE: [widgets PC] i18n comment 21: i18n string
(personal response) Having case-sensitive file/folder matching is going to lead to frustrated authors being unable to figure out why their localizations don't work. If there is no way to do case-less matching in the widget engine itself, I think your solution is workable. While it would be nice to recommend using the BCP 47 case conventions, if you don't, you need to really highlight the casing requirements in packaging. The original point of this editorial comment is that your XML examples should show the expected case folding of language tags. While perfectly legal to show them as all lowercase, it is just as legal to scream them in uppercase or use alternating case or otherwise make them look odd. By adding a recommendation to your document to use the case conventions in BCP 47 (which I see as unnecessary), but not using that recommendation in your examples, and then having a separate case convention buried elsewhere in your document you risk confusion. I think your text for the folder based localization section is good. I would put it directly following the first paragraph and I would reword it as follows: -- Although BCP 47 recommends a particular case-folding convention, the use of upper or lowercase letters has no meaning in a language tag. Because folders inside a widget package are treated by the user-agent in a case-sensitive manner, the names of the folders inside a 'locale' folder MUST be all lowercase. All language tags are mapped to lowercase for matching purposes (although they can appear in any form in the configuration file or elsewhere). -- And I would replace your text in The xml:lang Attribute section with a pointer to the warning above. Perhaps: -- Although BCP 47 recommends that language tags be casefolded in a particular way for presentation, case has no meaning in a language tag. Because user-agents map all language tags to lowercase because they treat file names in a case-sensitive manner, all examples in this document use lowercase as a reminder to authors. See [[folder-based localizations]]. -- Addison Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture. -Original Message- From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- requ...@w3.org] On Behalf Of Marcos Caceres Sent: Tuesday, June 29, 2010 7:08 AM To: Richard Ishida Cc: public-i18n-c...@w3.org; public-webapps@w3.org Subject: Re: [widgets PC] i18n comment 21: i18n string On Fri, May 28, 2010 at 8:38 AM, Richard Ishida ish...@w3.org wrote: Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 21 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: General Comment: Language tags are presented as lowercase. While case has no meaning in language tags, they are typically canonicalized (and are recommended to use) the case conventions in BCP 47. See http://tools.ietf.org/html/bcp47#section-2.1.1 That is no problem for when language tags appear in xml:lang, as they are cononicalized to lower-case. However, following BCP 47 would cause issues with matching folders, as they are treated as case sensitive. In the Folder-based localization section, I've added the following to the authoring guidelines: Because folders inside a widget package are treated by the user agent as case sensitive, the names of the folders inside a locale folder need to be in lower-case. Unfortunately, this violates the case conventions recommended in BCP 47. In the The xml:lang Attribute section of the spec, I've added the following to the authoring guidelines: Please note that, while case has no meaning in language tags, it is recommend that with xml:lang authors use the case conventions recommended in BCP 47. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: ISSUE-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
On Thu, Jun 24, 2010 at 5:09 PM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-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. http://www.w3.org/2008/webapps/track/issues/117 Proposed solution: I've defined a Displayable-string attribute: An attribute whose primary purpose is to convey human readable information, such as the name element's short attribute and the widget element's version attribute. As just stated, the widget element's version attribute becomes a displayable-string attribute. So does the short attribute of the name element. The author's email attribute is now treated as a keyword attribute (hence, dir is not applied to it). I know this is not ideal, but it's a cheap solution and saves having to define yet another type of attribute. The name and value of the param attributes are now defined as keyword attributes (hence, dir is not applied to them). The dir attribute is now defined as A keyword attribute used to specify the directionality in which human-readable text is to be represented by a user agent (e.g., the text content of the name element, the description element, and the license element). The directionality set by the dir attribute applies to the text content and any displayable string attributes of the element where it is used, and to child elements in its content unless overridden with another instance of dir. The Rule for Getting a Single Attribute Value now only returns a localized string if and only if the attribute is a displayable-string attribute. Hence, all attributes are processed as strings and dir has no effect on them. The Rule for Getting a List of Keywords From an Attribute no longer returns a localized string (as directionality does not apply to this kind of attribute). -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [widgets PC] i18n comment 21: i18n string
On 6/29/10 5:36 PM, Phillips, Addison wrote: (personal response) Having case-sensitive file/folder matching is going to lead to frustrated authors being unable to figure out why their localizations don't work. I know, but implementers complained that it's just too slow to do it any other way :( If there is no way to do case-less matching in the widget engine itself, I think your solution is workable. It is possible (this was Opera's implementation's default behavior); it's just hard for implementers apparently. While it would be nice to recommend using the BCP 47 case conventions, if you don't, you need to really highlight the casing requirements in packaging. I've changed the spec to clarify this: This specification defines the concept of folder-based localization, which is the process whereby an author places files inside folders that are named in a manner that conforms to a language-range ABNF rule of this specification. That is, by naming folders in lower-case using values derived from the IANA Language Subtag Registry such as en-us, en-gb, and so on, but avoiding subtags marked as deprecated, grandfathered, or redundant in the IANA Language Subtag Registry. These locale folders are then placed inside the container for localized content. The language-range rule is: language-range = (1*8low-alpha / *) *(- (1*8alphanum / *)) alphanum = low-alpha / DIGIT low-alpha = %x61-71 The original point of this editorial comment is that your XML examples should show the expected case folding of language tags. While perfectly legal to show them as all lowercase, it is just as legal to scream them in uppercase or use alternating case or otherwise make them look odd. By adding a recommendation to your document to use the case conventions in BCP 47 (which I see as unnecessary), but not using that recommendation in your examples, and then having a separate case convention buried elsewhere in your document you risk confusion. Argh, right :( I think your text for the folder based localization section is good. I would put it directly following the first paragraph and I would reword it as follows: -- Although BCP 47 recommends a particular case-folding convention, the use of upper or lowercase letters has no meaning in a language tag. Because folders inside a widget package are treated by the user-agent in a case-sensitive manner, the names of the folders inside a 'locale' folder MUST be all lowercase. All language tags are mapped to lowercase for matching purposes (although they can appear in any form in the configuration file or elsewhere). -- Yes, much better. Thank you. And I would replace your text in The xml:lang Attribute section with a pointer to the warning above. Perhaps: -- Although BCP 47 recommends that language tags be casefolded in a particular way for presentation, case has no meaning in a language tag. Because user-agents map all language tags to lowercase because they treat file names in a case-sensitive manner, all examples in this document use lowercase as a reminder to authors. See [[folder-based localizations]]. -- Adapted it a little bit (the Because...because... caused me some confusion.). Hope this is ok: Although [BCP47] recommends that language tags be casefolded in a particular way for presentation, case has no meaning in a language tag. As a reminder to authors that user-agents map all language tags to lowercase, all examples in this document use lowercase. See also [folder-based localization], which also requires authors to use language tags in lowercase form as the names of folders. Thanks again, Addison, for all your time and help! -- Marcos Caceres Opera Software
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On 6/28/10 6:58 PM, Eric Uhrhane wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? I personally think this sounds workable. We could also have a responseArrayBuffer using the TypedArrays[4] proposal which wouldn't necessarily need asynchronous processing. -- A* Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html [3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: [File API] Recent Updates To Specification + Co-Editor
Hi Arun, On 28.06.2010 23:20, Arun Ranganathan wrote: ... 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. ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. That being said, nits below: - it's a URI scheme, not a URL scheme - you want to use RFC 5234, not 2234 for ABNF (that just changes the reference) - MAY use UUIDs doesn't make sense if it's really opaque. I'll assume that opaqueString will allow all characters used in UUIDs, so you really don't need a BCP 14 keyword here. Just state that it might be a good choice. - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) I recommend to do another round of edits on this, and then include the URI review mailing list into further discussions. Best regards, Julian
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? SGTM Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html [3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. / Jonas
Re: [File API] Recent Updates To Specification + Co-Editor
On 6/29/10 11:09 AM, Julian Reschke wrote: Hi Arun, On 28.06.2010 23:20, Arun Ranganathan wrote: ... 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. ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. Both you and I may sound like broken records, since we've definitely been down this road before :) I do plan to register it via IANA. Note that we started off with a URN scheme (urn:uuid). This was chosen initially to bypass a cycle with IANA, but this wasn't adequate. No browser implementation really uses URN schemes; they aren't used in web pages; implementers, including Firefox, cited a preference for URLs with a scheme (for instance, nightly builds of Firefox use moz-filedata: as a scheme). Moreover, we wanted something that could be used in all places on the web platform that URLs are used today, including Web APIs like XMLHttpRequest, and for elements (like img src..). Lastly, while a URN scheme could have been used with an attribute called URL, that seemed wrong. We have file URIs (file://) on the web platform today, and some implementations actually support use such as that mentioned above. But a scheme that referred to individual Blobs or Files that could be used with response codes was the best course of action (with no path, etc.). That being said, nits below: - it's a URI scheme, not a URL scheme Duly noted; this is a mistake on my part. - you want to use RFC 5234, not 2234 for ABNF (that just changes the reference) Duly noted; I'll fix this. - MAY use UUIDs doesn't make sense if it's really opaque. I'll assume that opaqueString will allow all characters used in UUIDs, so you really don't need a BCP 14 keyword here. Just state that it might be a good choice. Hmm... fair enough. - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? It is likely to be unique per producer. In fact, Chrome folks may wish to use origin tokens in the URI scheme, and even if they didn't, the use of UUID would result in differences per producer. If by different producers, you mean that a Blob URI coined by Chrome may have no meaning in Firefox, you're likely to be right. While the *format* that the URI takes may vary per producer, it seems wise to at least define a scheme that can be used commonly by user agents. Authors may never interact with the URI itself, but only with the Blob.url property -- that is true. But at least a scheme gets us something that's better than total arbitrariness. Do you disagree strongly? I also think that leaving things undefined isn't desirable in general. - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself That's right. I want to emphasize that they are allowed. I took this from the RFC on WWW URIs, cited in the text. Maybe I can add a non-normative section on the use of fragment identifiers? Is that your suggestion? - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) Right -- I do in the spec. They depend entirely on the media type of a Blob. Is the existing text insufficient? I recommend to do another round of edits on this, and then include the URI review mailing list into further discussions. Good suggestion, thanks Julian. -- A*
Re: [File API] Recent Updates To Specification + Co-Editor
On 29.06.2010 20:40, Arun Ranganathan wrote: ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. Both you and I may sound like broken records, since we've definitely been down this road before :) I know :-) I do plan to register it via IANA. Note that we started off with a URN scheme (urn:uuid). This was chosen initially to bypass a cycle with IANA, but this wasn't adequate. No browser implementation really uses URN schemes; they aren't used in web pages; implementers, including Firefox, cited a preference for URLs with A URN is a URI. blob is a would-be URI as well. No web page uses blob right now, so I'm not sure what point you're trying to make. a scheme (for instance, nightly builds of Firefox use moz-filedata: as a scheme). Moreover, we wanted something that could be used in all places on the web platform that URLs are used today, including Web APIs like XMLHttpRequest, and for elements (like img src..). Lastly, while a URN scheme could have been used with an attribute called URL, that seemed wrong. I don't see why you can't do these things with urn:uuid:. We have file URIs (file://) on the web platform today, and some implementations actually support use such as that mentioned above. But a scheme that referred to individual Blobs or Files that could be used with response codes was the best course of action (with no path, etc.). All true understood; but I still don't see why this needs a new URI scheme. ... - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? It is likely to be unique per producer. In fact, Chrome folks may wish to use origin tokens in the URI scheme, and even if they didn't, the use of UUID would result in differences per producer. If by different producers, you mean that a Blob URI coined by Chrome may have no meaning in Firefox, you're likely to be right. So if a blob URI produced by Firefox leaks into Chrome, what happens? If this *can* happen, you may need to require more than per-producer uniqueness. While the *format* that the URI takes may vary per producer, it seems wise to at least define a scheme that can be used commonly by user agents. Authors may never interact with the URI itself, but only with the Blob.url property -- that is true. But at least a scheme gets us something that's better than total arbitrariness. Do you disagree strongly? I also think that leaving things undefined isn't desirable in general. I actually do not see what benefit this scheme brings. - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself That's right. I want to emphasize that they are allowed. I took this from the RFC on WWW URIs, cited in the text. Maybe I can add a non-normative section on the use of fragment identifiers? Is that your suggestion? The semantics of fragment identifiers follow from RFC 3986, Section 3.5 (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5) and the media type that is being retrieved. So normative statements would be incorrect, but explaining what's going on wouldn't hurt. - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) Right -- I do in the spec. They depend entirely on the media type of a Blob. Is the existing text insufficient? I didn't see it. Most is accurate. I'd rephrase This scheme can allow for fragment identifiers for well-defined format types though. The scheme can't allow or disallow anything; it really only depends on the media types of the representations you get upon deref. ... Best regards, Julian
[Bug 10052] New: Specify setVersion details
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
Summary: Specify setVersion details
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: jo...@sicking.cc
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
In the thread started at [1] there were some discussions about how setVersion
should work. It seems like there was consensus (at least among the participants
in the thread) for the following behavior
When setVersion(X) is called, perform the following steps:
1. Create a IDBRequest object, /request/.
2. If there are no other IDBDatabase objects open to the same database, skip to
next step.
Otherwise, asynchronously fire a versionchange event targeted at those
IDBDatabase objects. The versionchange event implements a
IDBVersionChangeEvent interface defined below, and has the 'version' property
is set to X. Also asynchronously fire a 'blocked' event on /request/.
3. Return the /request/ object and finish the setVersion call.
4. Once all other IDBDatabase objects are closed, initiate a transaction with
mode VERSION_CHANGE. As long as this transaction is open, no other IDBDatabase
objects can be opened to the same database.
5. Fire a 'success' event on /request/ with .transaction set to the transaction
created in step 5.
6. Follow the normal steps for transactions (i.e. allow requests to be placed,
etc)
When createObjectStore/createIndex/removeObjectStore/removeIndex is called,
perform the following steps:
1. If we're not currently firing a 'success' event on a VERSION_CHANGE
transaction, throw an exception. I.e. only 'success' event handlers inside a
VERSION_CHANGE transaction can make schema related modifications. However note
that it's not just the 'success' event from the original setVersion call that
is allowed to make schema changes. You can also make them from, for example,
the success event fired after a 'get' request, as long as that 'get' request
was made on a VERSION_CHANGE transaction.
2. If removeObjectStore or removeIndex is called, remove the relevant object if
it exists and return from the function. If it doesn't exist, do nothing and
return from the function.
3. If createObjectStore/createIndex is called with invalid parameters, such as
an invalid keyPath, throw an exception. Likewise, if the objectStore or index
already exists, throw an exception.
4. Create the requested object and add it to the database. Return the newly
created object and return from the function.
Add a .close() function to IDBDatabase. When the function is called, perform
the following steps:
1. Set a internal /closePending/ flag to true. If .transaction is called, and
/closePending/ is true, an exception is thrown (or should we just make
.transaction return null?)
2. Once all pending transactions are finished, the IDBDatabase is fully closed.
This unblocks any pending setVersion calls made on other IDBDatabase objects
connected to the same database.
IDL for related APIs:
IDBDatabase {
...
IDBObjectStore createObjectStore(in DOMString name,
[TreatNullAs=EmptyString]
in optional DOMString keyPath,
in optional boolean autoIncrement);
readonly attribute bool closePending;
void close();
...
};
IDBObjectStore {
...
IDBIndex createIndex(in DOMString name, in DOMString keyPath,
in optional boolean unique);
...
};
interface IDBVersionChangeEvent : IDBEvent {
readonly attribute string version;
};
[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1141.html
--
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: [IndexedDB] Atomic schema changes
On Sun, Jun 27, 2010 at 12:27 AM, Jonas Sicking jo...@sicking.cc wrote:
But, I feel pretty strongly that a setVersion/schema change
transaction
should not simply kill off anything else currently running. The
reason
is
that it's not hard for apps to recover from a connection failing, but
it
is
hard to handle a transaction failing in an unpredictable way.
Especially
static transactions (which should rarely fail committing since
serialization
can be guaranteed before the transaction starts).
That might be a good idea for v1. I was planning on doing a separate
thread for setVersion, but maybe it's tied enough to the topic of
schema changes that it makes sense to bring up here.
What I suggest is that when setVersion is called, we fire
'versionchange' event on all other open IDBDatabase objects. This
event contains information of what the desired new version number is.
If no other IDBDatabase objects are open for the specific database, no
'versionchange' events are fired. This allows pages using the old
schema version to automatically save any pending data (for example any
draft emails) and display UI to the user suggesting that the tab be
closed. If possible without dataloss, the tab could even reload itself
to automatically load an updated version of the page which uses the
new schema version.
The 'versionchange' event would use an interface like
interface IDBVersionEvent : IDBEvent {
readonly attribute string version;
};
First of all, what I was originally advocating (sorry for not being
clear)
is that we should kill the database connection but not until all active
transactions are complete. Though we should probably block new
transactions
from starting once setVersion is called.
But I really like your versionchange event idea regardless. I agree
that
letting the app sync any data that might be in memory (for example, a
draft
email) is important. And the idea that the web app could refresh itself
(or
download new application code or something) seems pretty cool and
useful.
I'm fine with it firing on all frames except the one that initiated
(like
storage events). If we go with the kill the connection once all active
transactions are done and block new ones from starting, we'd want to
start
the blocking only after all versionchange events have finished.
The main reason that I like the idea of not stating the version change
until
all active connections have closed is that not all apps will handle
versionchange. My original idea was that we should just break such web
apps
and let the user refresh, but now that you've pointed out the potential
for
data loss I'm not sure that's an option. Savvy web apps can kill all
existing database connections when they get the versionchange and thus
avoid
stalling things.
Additionally, if there are open IDBDatabase objects, we fire a
'blocked' event at the IDBRequest object returned from the setVersion
call. This allows the page to display UI to the user asking the user
to close all other relevant tabs.
Once all other IDBDatabase objects are closed, we create a transaction
and fire the normal 'success' event.
While there are pending version change requests, no success events are
fired for calls to IDBFactory.open for the relevant database.
We might want to support forcefully killing off open IDBDatabase
objects in the future, but I think that can wait until after v1.
Really? I can't see an app like gmail ever asking users to close tabs.
I
bet they'd sooner run all the application logic in an iframe and
navigate it
away when doing a schema change.
And I don't see many people correctly implementing a blocked event
handler.
If anything, it should be an error code.
It doesn't seem that hard to have an explicit way to tell the database
explicitly OK, I'm done. Or, at very least, we could make it so that
when
there's an existing setVersion happening, all new connection requests
stall.
That way all pages can reload themselves but they won't connect to the
database until the upgrade is complete.
But really...all of this is really hacky. I'm starting to wonder if we
should just kill the database connections on a setVersion as I
originally
tried to suggest.
I'm pretty concerned though that sites will need to take asynchronous
actions in order to save all required data. While gmail happily
automatically saves every few minutes, and presumably could
immediately do so upon a 'versionchange' event, I don't think all
editors are willing t. For example many editors ask the user if they
want to save the current changes when they are closed, in order to not
overwrite correct data.
Additionally, there is always the risk that developers will forget to
use a versionchange event handler to protect their data. I think a
good design principal is that if sites do
RE: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. The fact that the XHR spec says the events do not bubble (but says nothing about capture) is confusing. DOM L3 Events says here's what happens for DOM elements, but doesn't say explicitly if NOTHING should happen for non-DOM uses, or if something else should depending on context. -Chris -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Friday, June 25, 2010 9:59 AM To: Brett Zamir Cc: Anne van Kesteren; www-...@w3.org; public-webapps@w3.org; Travis Leithead; Adrian Bateman; Chris Wilson Subject: Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects On 6/25/10 5:56 AM, Brett Zamir wrote: I guess in Firefox the document is all part of one big tree that includes the add-on markup, so propagation is indeed within the same DOM tree It's not, actually. In Firefox, an event will bubble from a Window to some object in the browser UI associated with that Window. This object is the same for a page and all its subframes. What this object is is effectively an implementation detail. Note that we plan to keep this behavior as we move to a multi-process architecture, at which point the event will effectively bubble across the process boundary. -Boris
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. I don't see Blob mentioned in the structured clone algorithm, although File is there. I doubt it would be much additional work to support all Blobs. Eric
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Jun 29, 2010 at 4:24 PM, Eric Uhrhane er...@google.com wrote: On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. I don't see Blob mentioned in the structured clone algorithm, although File is there. I doubt it would be much additional work to support all Blobs. Indeed, it should be trivial. I think Blob didn't exist yet at the time when the structured clone algorithm was last updated. / Jonas
BlobWriter simplification/split
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? [Better names for SimpleBlobWriter and BlobWriter would be quite welcome, BTW.] Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0910.html [buried rather deep in the thread] [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1206.html
