[Bug 19450] [IndexedDB] Key path segments should permit reserved words
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19450 Joshua Bell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Joshua Bell --- https://dvcs.w3.org/hg/IndexedDB/rev/c6b12332f5ae -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 16513] Use WebIDL enum for IDBDatabase.transaction's mode argument
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16513 Joshua Bell changed: What|Removed |Added Status|NEW |RESOLVED CC||jsb...@chromium.org Resolution|--- |FIXED --- Comment #2 from Joshua Bell --- Spec updated: https://dvcs.w3.org/hg/IndexedDB/rev/f3d40c6295ac * TransactionMode enum declared using WebIDL, definitions of "readonly", "readwrite", "versionchange" incorporated * IDBDatabase.transaction() and IDBDatabaseSync.transaction() updated in WebIDL to reference TransactionMode enum and prose to drop explicit references to throwing TypeError. * IDBTransaction.mode and IDBTransactionSync.mode updated to reference TransactionMode enum -- You are receiving this mail because: You are on the CC list for the bug.
Re: [admin] Towards XHR "The Attorney's Edition"
On Thu, 28 Feb 2013 15:46:34 +0100, Arthur Barstow
wrote:
Last year we agreed to stop work on the "baseline" XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version is to specify features that are widely
implemented and deployed today. As such, it _should_ be relatively
straight forward to move this version to LC and then to CR->PR->REC and
thus "finalize" the IP commitments by WebApps' members. (There are no
firm IP commitments for XHR until a REC is published.)
My proposal is to use the "XMLHttpRequest1" shortname for the baseline
version, the same shortname as the XHR WG Note published 17 January 2012
[XHR-Note]. Thus, the first TR publication of the new baseline spec
would "replace" the WG Note (although the dated version of the WG Note
[XHR-Note-Dated] will of course be untouched).
I don't feel strongly about the title of the baseline version. Some
options: "XMLHttpRequest Baseline", "XMLHttpRequest Level {0,1}" and I
could live with something like "XMLHttpRequest: The Attorney's Edition
[v{0,1}]".
Comments?
Much as I love it, I don't think "The attorney's edition" is a helpful
addition to the title. Besides, I think it is valuable for people for
reasons other than just fulfilling the patent policy requirements.
Since we expect this to basically be the stuff in what used to be called
XMLHttpRequest level 1 that is actually widely implemented (ie really
standard, not just the things we think should be), I think XMLHttpRequest
level 1 makes a pretty sensible real name.
cheers
Chaals
-Art and Chaals
[XHR-Note]
Request for Review: Test cases for Web Messaging; deadline March 28
We have submitted 30 test cases for Web Messaging CR [CR]. They are available here: http://w3c-test.org/webapps/WebMessaging/tests/submissions/Microsoft/ Please consider this email our Request for Review [RfR] for the test cases listed below with a proposed deadline for comments of March 28, 2013. If you have any comments, please send them to public-webapps-testsu...@w3.org by the deadline. If you review any set of the tests and find no issues, please state that as a reply to this RfR too. [1] Channel_MessagePort_initial_disabled.htm [2] Channel_MessagePort_onmessage_start.htm [3] Channel_postMessage_DataCloneErr.htm [4] Channel_postMessage_clone_port.htm [5] Channel_postMessage_clone_port_error.htm [6] Channel_postMessage_event_properties.htm [7] Channel_postMessage_ports_readonly_array.htm [8] Channel_postMessage_target_source.htm [9] MessageEvent_properties.htm [10]Transferred_objects_unusable.htm [11]event.data.htm [12]event.origin.htm [13]event.ports.htm [14]event.source.htm [15]event.source.xorigin.htm [16]postMessage_ArrayBuffer.htm [17]postMessage_Date.htm [18]postMessage_Document.htm [19]postMessage_Function.htm [20]postMessage_MessagePorts_sorigin.htm [21]postMessage_MessagePorts_xorigin.htm [22]postMessage_arrays.htm [23]postMessage_asterisk_xorigin.htm [24]postMessage_dup_transfer_objects.htm [25]postMessage_invalid_targetOrigin.htm [26]postMessage_objects.htm [27]postMessage_origin_mismatch.htm [28]postMessage_origin_mismatch_xorigin.htm [29]postMessage_solidus_sorigin.htm [30]postMessage_solidus_xorigin.htm Thanks, Alex [RfR] http://www.w3.org/2008/webapps/wiki/Approval [CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[Bug 21147] WebSocket API could provide a method to get the HTTP response code when it's not 101
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21147 Art Barstow changed: What|Removed |Added CC||art.bars...@nokia.com, ||public-webapps@w3.org Component|HTML5 spec |WebSocket API (editor: Ian ||Hickson) Assignee|dave.n...@w3.org|i...@hixie.ch Product|HTML WG |WebAppsWG QA Contact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3. ||org -- You are receiving this mail because: You are on the CC list for the bug.
Re: Streams and Blobs
On Wed, Feb 27, 2013 at 5:26 PM, Glenn Maynard wrote: > I'm simply asking: what use cases there are for creating a stream with XHR > and handing the stream off to another API, that can't be done much more > simply by handing a URL to the other API in the first place? > I've trimmed off the rest of the discussion since this appears to be the primary question you want answered. I just wanted to use this email to capture the use case that I care about most right now. One of the primary use cases for MSE is adaptive streaming. Early in MSE spec development I suggested just using URLs as you proposed. When I did that, it became clear that I needed to address several other requirements as well. - Add the ability to specify range requests - Provide different cross-origin info for each request - Report status events during the transfer so the application could display progress and estimate available bandwidth - Report network error codes - Abort the transfer early if the application determines that it isn't worth pulling down the rest of the data. As I started to address each one of these, I began to realise that I was just replicating what XHR does already. XHR had everything I needed except two things. 1. The ability to transfer the data to the MSE objects w/o surfacing the bytes to JavaScript. (Our friends in the mobile space care about this a lot.) 2. The ability to consume the bytes as they arrive during the transfer. (Our friends who want quick startup times and low latency care about this a lot.) When I saw the Stream API and the proposal to add it to XHR, I saw a solution to all the issues I needed to address. It seemed like it would have very low impact on how XHR would work and it allowed people to leverage their existing XHR knowledge to formulate the requests they needed. This is not theorical. Early adopters of MSE are already building adaptive streaming solutions with standard XHR and really want to see solutions for items 1 & 2. I hope this helps you understand a bit where I'm coming from. Aaron
Re: Streams and Blobs
On Thu, Feb 28, 2013 at 12:13 AM, Darin Fisher wrote: > It's a fair question, and I think you've made a lot of good points. I > think XHR gives you the ability to customize the HTTP request. You can set > custom request headers, customize the request method, control cross-origin > behavior, etc. It gives the developer a lot of flexibility. > I just think the complexity hasn't been justified with actual use cases for that flexibility. Another thing not to lose sight of is that a Stream abstraction could be > useful as an optimization tool. There are times when a developer just > needs to connect a data stream from a provider to a consumer and doesn't > necessarily care about seeing the raw bytes. (The data may not even be > available in the address space of the process running the developer's > script.) So, I can imagine some optimization opportunities when we work > with a handle to a stream of data rather than the data itself. > Blob is already a handle to data that can be passed around without having the data it represents in memory. It's ArrayBuffer that usually represents actual, in-memory data. Blob is already meant to allow these optimizations. On Thu, Feb 28, 2013 at 1:07 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Also, the Stream object lets you pipe the data from to/from Web Workers, which can be handy in certain scenarios. What's wrong with just posting a Blob or ArrayBuffer? -- Glenn Maynard
[admin] Towards XHR "The Attorney's Edition"
Last year we agreed to stop work on the "baseline" XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version is to specify features that are widely
implemented and deployed today. As such, it _should_ be relatively
straight forward to move this version to LC and then to CR->PR->REC and
thus "finalize" the IP commitments by WebApps' members. (There are no
firm IP commitments for XHR until a REC is published.)
My proposal is to use the "XMLHttpRequest1" shortname for the baseline
version, the same shortname as the XHR WG Note published 17 January 2012
[XHR-Note]. Thus, the first TR publication of the new baseline spec
would "replace" the WG Note (although the dated version of the WG Note
[XHR-Note-Dated] will of course be untouched).
I don't feel strongly about the title of the baseline version. Some
options: "XMLHttpRequest Baseline", "XMLHttpRequest Level {0,1}" and I
could live with something like "XMLHttpRequest: The Attorney's Edition
[v{0,1}]".
Comments?
-Art and Chaals
[XHR-Note]
Re: Streams and Blobs
On Wed, Feb 27, 2013 at 10:03 PM, Cyril Concolato
wrote:
> I was confused when reading only:
> "The arraybuffer response entity body is an ArrayBuffer representing the
> response entity body."
> and then:
> "The response entity body is the fragment of the entity body of the response
> received so far (LOADING) or the complete entity body of the response
> (DONE)."
> It is true that step 1 in the "otherwise" statement in 4.7.8 ("if the state
> is not DONE, return") is clear. It would probably be better if the text was
> only in one place.
It cannot be in one place because you have to return the same object.
So you need some place where you create that object and then keep
returning it from there.
> Ok, I think I agree with you. In summary, we'd have:
> blob: .response = full data as a Blob, on DONE, null otherwise.
> arraybuffer: .response = full data, on DONE, null otherwise.
> moz-blob: .response = a different blob object containing partial data (not
> overlapping with previous/next blobs), on LOADING and DONE, null otherwise.
Note that you get the same Blob if nothing changed.
> moz-chunked-arraybuffer: .response = a different arraybuffer object
> containing partial data (non-overlapping), on LOADING and DONE, null
> otherwise.
> moz-chunked-text: .responseText = a different string object containing
> partial data (non-overlapping), on LOADING and DONE, null otherwise.
> Is that correct?
moz-chunked-text goes via .response too, but I'm not sure that's worth
having given the majority case seems ArrayBuffer and we have
TextDecoder in case that's not sufficient.
--
http://annevankesteren.nl/
Re: Streams and Blobs
On Thu, Feb 28, 2013 at 7:07 AM, Travis Leithead wrote: > Also, the Stream object lets you pipe the data from to/from Web Workers, > which can be handy in certain scenarios. Hey Travis, could you maybe reply to my original or at least some of the earlier emails that discuss the semantics of Stream and which kind of things we might want to expose? It'd be great to have your feedback on that especially as Microsoft thus far has the only implementation of Stream (I believe). It sounds like everyone wants to keep something like Stream, one that when read from discards data. (Which might be problematic if you pass it both to and use a StreamReader, or multiple StreamReader objects.) It'd be good to have more feedback on chunked too and whether or not we want to expose incremental Blob (new object each time you get .response if additional data has been transferred, otherwise the same object). -- http://annevankesteren.nl/
