gmane.org.w3c.appformats

IndexedDB: ambiguity around IDBTransaction.error

Alec Flett — 2012-05-25T20:16:21

I have found what feels like an ambiguity in the spec around
IDBTransaction.error and when it is available.

In particular, the spec says:



The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction itself
is complete, the 'error' attribute should be the error that caused the
transaction to abort, if any. So the question is, which 'done' flag does
this correspond to - the done flag on the current request, the done flag on
the request that caused the abort, or some other 'done' state about the
transaction itself.

An example:

transaction = ...
transaction.objectStores("foo").put(badValue).onerror = function(event) {
  // can I access transaction.error here?

  // the request has its own error though.
  requestError = event.target.error;

  transaction.objectStores("foo").put(goodValue).onsuccess =function(event)
{
  // can I access transaction.error here? If so, is it requestError, or is
it null?
  }
}

transaction.objectStore

[Bug 17198] New: Remove mention of IDBVersionChangeRequest

2012-05-25T23:09:09

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17198

           Summary: Remove mention of IDBVersionChangeRequest
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null< at >w3.org
        ReportedBy: jonas< at >sicking.cc
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: mike< at >w3.org, public-webapps< at >w3.org


The interface no longer exists, and the place where it's mentioned already
talks about the correct interface as well.

[Bug 17196] New: (Note: Your IP address and user agent will be publicly recorded for spam prevention purposes.)

2012-05-25T21:09:25

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17196

           Summary: (Note: Your IP address and user agent will be publicly
                    recorded for spam prevention purposes.)
           Product: WebAppsWG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian< at >hixie.ch
        ReportedBy: contributor< at >whatwg.org
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: mike< at >w3.org, public-webapps< at >w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
(Note: Your IP address and user agent will be publicly recorded for spam
prevention purposes.) 

Posted from: 46.254.209.162
User agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101

[Bug 17192] New: Trying to find the music i downloaded

2012-05-25T18:35:10

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17192

           Summary: Trying to find the music i downloaded
           Product: WebAppsWG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Web Storage (editor: Ian Hickson)
        AssignedTo: ian< at >hixie.ch
        ReportedBy: contributor< at >whatwg.org
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: ian< at >hixie.ch, mike< at >w3.org, public-webapps< at >w3.org


Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Trying to find the music i downloaded

Posted from: 174.141.208.99
User agent: HUAWEI-M735/001.00 Opera/9.70

[Bug 17184] New: Please don't use section numbers as these tend to change rapidly and make your feedback harder to understand.

2012-05-25T10:21:02

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17184

           Summary: Please don't use section numbers as these tend to
                    change rapidly and make your feedback harder to
                    understand.
           Product: WebAppsWG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian< at >hixie.ch
        ReportedBy: contributor< at >whatwg.org
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: mike< at >w3.org, public-webapps< at >w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Please don't use section numbers as these tend to change rapidly and make your
feedback harder to understand.

Posted from: 120.72.91.20
User agent: Mozilla/5

Proposal: Document.parse() [AKA: Implied Context Parsing]

Rafael Weinstein — 2012-05-25T07:01:43

Ok, so from consensus on earlier threads, here's the full API & semantics.

Now's the time to raise objections to UA's adding support for this feature.

-----

1) The Document interface is extended to include a new method:

DocumentFragment parse (DOMString markup);

which:
-Invokes the fragment parsing algorithm with markup and an empty
context element,
-Unmarks all scripts in the returned fragment node as "already started"
-Returns the fragment node

2) The fragment parsing algorithm's context element is now optional.

It's behavior is similar to the case of a known context element, but
the tokenizer is simply set to the data state

3) Resetting the insertion appropriately now sets the mode to "Implied
Context" if parsing a fragment and no context element is set, and
aborts.

4) A new "Implied Context" insertion mode is defined which

-Ignores doctype, end tag tokens
-Handles comment & character tokens as if "in body"
-Handles the following start tags as if "in body" (which is as if "in
head"): <style>, <s

http://www.w3.org/TR/2012/WD-url-20120524

Julian Reschke — 2012-05-24T18:06:03

Hi there,

here's some early feedback.

"A control character is a character whose value is less than or equal to 
U+0020 (" ")."

This is really surprising; it doesn't match Unicode 
(<http://www.unicode.org/charts/PDF/U0000.pdf>) nor IETF ABNF (RFC 5234).

I think it would be better to exclude U+0020, in particular as the term 
is just only once.

A more general concern is that the spec defines various URI-related 
operations in terms of algorithms, and doesn't mention whether those 
algorithms are supposed to return the same results as those defined in 
RFC 3986 or not.

If they are not, it would be totally awesome if there was an explanation 
about what these difference are. Lacking that, this is really hard to 
review.

Best regards, Julian

RfC: LCWD of WebSocket API; deadline June 14

Arthur Barstow — 2012-05-24T17:20:50

This is a Request for Comments re the 24-May-2012 LCWD version of the 
WebSocket API:

http://www.w3.org/TR/2012/WD-websockets-20120524/

The comment deadline is June 14 and all comments should be sent to the 
public-webapps< at >w3.org list. The Bugzilla component for the API is [Bugz].

I Cc'ed the hybi list as an FYI and comments from that list's 
subscribers are of course welcome. The Bugzilla component for the API is 
[Bugz].

-Thanks, AB

[Bugz] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=WebSocket%20API%20%28editor%3A%20Ian%20Hickson%29&resolution=---

RfC: LCWD of Indexed Database; deadline June 21

Arthur Barstow — 2012-05-24T17:20:20

This is a Request for Comments re the 24-May-2012 LCWD version of 
Indexed Database:

http://www.w3.org/TR/2012/WD-IndexedDB-20120524/

The comment deadline is June 21 and all comments should be sent to the 
public-webapps< at >w3.org list.

-Thanks, AB

Non-persistent in-memory storage accessible by same domain tabs

Joran Greef — 2012-05-24T13:42:23

Web applications need a way to communicate between two same domain
tabs without polling LocalStorage and without hitting the disk.

It would be useful to have an in-memory get/set/compare_and_set hash
table exposed to scripts running same domain tabs, that is discarded
by the browser when those tabs are closed.

Use cases:

1. Coordinate replication between tabs for an offline app, i.e. one
tab takes responsibility for syncing a user's data to and from
IndexedDB.
2. Sign out from one tab triggers sign out from all other tabs.
3. If something like LevelDB were exposed directly to JS, one could
implement MVCC on top using the shared hash.
4. Library authors would be able to implement their own cross-tab postMessage.

It's difficult to implement these use cases with LocalStorage, without
a coarse resolution, and risky at that, due to the lack of compare and
set primitive in LocalStorage.

URL spec parameter-related methods use "parameter" in a way inconsistent with the URI RFC

Maciej Stachowiak — 2012-05-24T09:29:24

The current draft URL spec has a number of Parameter-related methods (getParameterNames, getParameterValues, hasParameter, getParameter, setParameter, addParameter, removeParameter, clearParameters)[1]. Apparently these methods refer to key-value pairs in the query part of the URL as "parameters". However, the term "parameter" is used by the URI RFC[2] to refer to something else, a semicolon-delimited part of a path (which I think is nearly obsolete in modern use; I am not sure what it is for). I understand that for legacy reasons, much of the URL interface cannot be consistent with RFC-official terminology. But it seems like a bad idea to use the same term for a different piece of the URL, worse than using the same term for a different part. At least call it something like "query paramete
 rs" to disambiguate.

Another point of feedback on the parameter-related methods: they seem to form a dictionary-style interface, and it seems inelegant to have all these different methods giving a dictionary-style inter

Push API draft uploaded

SULLIVAN, BRYAN L — 2012-05-24T07:14:00

Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API
http://dvcs.w3.org/hg/push/raw-file/default/index.html

I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Services/Notifications/Push/API as the "PushManager" interface, and also in the "PushService" interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events.

A lot is still left unsaid, and I will work on examples.

I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the "backend"

DOMParser Errors Should Be Exceptions

Yehuda Katz — 2012-05-23T19:03:19

In the current DOM parsing spec[1], errors in XML (or SVG) are handled as
follows:

its
describe

In practice, browsers implement error handling in this way. The output for
the following code is given below.

(new XMLSerializer).serializeToString((new
DOMParser).parseFromString("<tr>hi", "text/xml"));

As a result, jQuery looks for a parserror tag and re-raises an error when
parsing XML[2].

In my view, the DOMParser should throw an exception, and not insert a
partially unspecified parserror tag.

Thoughts?

=== Output

Webkit:

"<tr><parsererror xmlns="http://www.w3.org/1999/xhtml" style="display:
block; white-space: pre; border: 2px solid #c77; padding: 0 1em 0 1em;
margin: 1em; background-color: #fdd; color: black"><h3>This page contains
the following errors:</h3><div
style="font-family:monospace;font-size:12px">error on line 1 at column 7:
Extra content at the end of the document
</div><h3>Below is a rendering of the page up to the first
error.</h3></parsererror>hi</tr>"

Firefox:

"<?xml-stylesheet href

New list: System Applications

Robin Berjon — 2012-05-23T15:36:07

Hi all,

there has recently been a fair amount of work and discussion about building entire operating systems using Web technology. As discussed on the DAP list, the W3C is currently putting together a charter for a "System Applications" group that would handle the specs required to write such applications.

Before the group is started, a mailing list has been set up in order to discuss various aspects of the draft charter and try to organise the work. You'll find all the details at:

    http://lists.w3.org/Archives/Public/public-sysapps/

Join and enjoy!

Howto spec

Anne van Kesteren — 2012-05-23T12:45:05

Hi,

I have made some updates to the "howto spec" wiki page outlining how
you should go about writing a specification, with some emphasis on
specifications for APIs.

http://wiki.whatwg.org/wiki/Howto_spec

In particular the "Patterns" and "Legacy DOM-style" sections are
probably of interest. I would love to have feedback to see what else
people would like to see explained or how what is explained thus far
can be done better.

Thanks,

[wbs] response to 'Call for Review: Widget Interface is W3C Proposed Recommendation'

2012-05-23T02:30:14

The following answers have been successfully submitted to 'Call for Review:
Widget Interface is W3C Proposed Recommendation' (Advisory Committee) for
MStar Semiconductor, Inc. by Jean-Charles Verdie.

Regarding the "Widget Interface" specification, the reviewer  supports
publication as a W3C Recommendation as is.

The reviewer's organization:
   - produces products addressed by this specification
   - expects to produce products conforming to this specification.

Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/widgetsapis/ until 2012-06-19.

 Regards,

 The Automatic WBS Mailer

[wbs] response to 'Call for Review: Widget Interface is W3C Proposed Recommendation'

2012-05-23T00:18:01

The following answers have been successfully submitted to 'Call for Review:
Widget Interface is W3C Proposed Recommendation' (Advisory Committee) for
Opera Software by Charles McCathieNevile.

Regarding the "Widget Interface" specification, the reviewer  supports
publication as a W3C Recommendation as is.

The reviewer's organization:
   - produces products addressed by this specification
   - expects to produce products conforming to this specification.
   - expects to produce content conforming to this specification.
   - expects to use products conforming to this specification.

Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/widgetsapis/ until 2012-06-19.

 Regards,

 The Automatic WBS Mailer

[wbs] response to 'Call for Review: Widget Interface is W3C Proposed Recommendation'

2012-05-22T20:15:01

The following answers have been successfully submitted to 'Call for Review:
Widget Interface is W3C Proposed Recommendation' (Advisory Committee) for
Nokia Corporation by Arthur Barstow.

Regarding the "Widget Interface" specification, the reviewer  supports
publication as a W3C Recommendation as is.

Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/widgetsapis/ until 2012-06-19.

 Regards,

 The Automatic WBS Mailer

[File API] File behavior under modification

Eric U — 2012-05-21T23:05:18

According to the latest editor's draft [1], a File object must always
return an accurate lastModifiedDate if at all possible.
"On getting, if user agents can make this information available, this
MUST return a new Date[HTML] object initialized to the last modified
date of the file; otherwise, this MUST return null."

However, if the underlying file has been modified since the creation
of the File, reads processed on the File must throw exceptions or fire
error events.
"...if the file has been modified on disk since the File object
reference is created, user agents MUST throw a NotReadableError..."

These seem somewhat contradictory...you can always look at the
modification time and see that it's changed, but if you try to read it
after a change, it blows up.
The non-normative text about security concerns makes me think that
perhaps both types of operations should fail if the file has changed
["... guarding against modifications of files on disk after a
selection has taken place"].  That may not be necessary,

IndexedDB: Binary Keys

Joran Greef — 2012-05-21T17:09:24

IndexedDB supports binary values as per the structured clone algorithm
as implemented in Chrome and Firefox.

IndexedDB needs to support binary keys (ArrayBuffer, TypedArrays).

Many popular KV stores accept binary keys (BDB, Tokyo, LevelDB). The
Chrome implementation of IDB is already serializing keys to binary.

JS is moving more and more towards binary data across the board
(WebSockets, TypedArrays, FileSystemAPI). IDB is not quite there if it
does not support binary keys.

Binary keys are more efficient than Base 64 encoded keys, e.g. a 128
bit key in base 256 is 16 bytes, but 22 bytes in base 64.

Am working on a production system storing 3 million keys in IndexedDB.
In about 6 months it will be storing 60 million keys in IndexedDB.

Without support for binary keys, that's 330mb wasted storage
(60,000,000 * (22 - 16)) not to mention the wasted CPU overhead spent
Base64 encoding and decoding keys.

[Bug 17125] New: Add a FileList.drop(index) method

2012-05-20T18:22:11

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125

           Summary: Add a FileList.drop(index) method
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
        AssignedTo: arun< at >mozilla.com
        ReportedBy: post< at >wickenrode.com
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: public-webapps< at >w3.org


Currently a FileList provided by a file input element is readonly.
This is problematic if the user added multiple files to a file list and then
sees that he included one file too much and want's to remove it before
uploading the files. Right now he can only start his selection from scratch. 
If there was a way to drop items from a FileList some JavaScript could display
a list of selected files and allow to remove items.