Re: Element.create(): a proposal for more convenient element creation
On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney domin...@google.com wrote: Third, is the order of attributes significant for XML namespace declarations? eg does this: x xmlns:foo=… foo:bar=… / mean the same thing as x foo:bar=… xmlns:foo=… / ? If not, including namespaces in the attribute dictionary is fraught, because the iteration order of properties is undefined. The order is unimportant when setting them via markup, but important when setting them via successive setAttribute calls. I'd prefer that the attribute bag be handled like markup attributes, where xmlns attributes are handled early so that later attributes fall into the correct namespace. ~TJ
Re: Element.create(): a proposal for more convenient element creation
On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney domin...@google.com wrote: Third, is the order of attributes significant for XML namespace declarations? eg does this: x xmlns:foo=… foo:bar=… / mean the same thing as x foo:bar=… xmlns:foo=… / ? If not, including namespaces in the attribute dictionary is fraught, because the iteration order of properties is undefined. The order is unimportant when setting them via markup, but important when setting them via successive setAttribute calls. I'd prefer that the attribute bag be handled like markup attributes, where xmlns attributes are handled early so that later attributes fall into the correct namespace. Is there a reason to support namespaced attributes at all? They are extremely rare, especially on the web. Ideally I'd like to deprecate them, but I suspect that's not doable. But I see no reason to support them in new APIs. / Jonas
Re: Element.create(): a proposal for more convenient element creation
On 8/6/11, Charles Pritchard ch...@jumis.com wrote: [...] I've stated in prior threads, that unless the word is aria-* or data-*, properties are set on the element. I see. But that's inherently inconsistent and mostly misleading (attr alludes to attribute not usually property except when it's data or aria). For setting properties, though, a `setOwnProperties` method could be convenient. -- Garrett
Re: Element.create(): a proposal for more convenient element creation
On 2011-08-08 10:17, Jonas Sicking wrote:
On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr.jackalm...@gmail.com wrote:
On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooneydomin...@google.com wrote:
Third, is the order of attributes significant for XML namespace
declarations? eg does this:
x xmlns:foo=… foo:bar=… /
mean the same thing as
x foo:bar=… xmlns:foo=… /
? If not, including namespaces in the attribute dictionary is fraught,
because the iteration order of properties is undefined.
The order is unimportant when setting them via markup, but important
when setting them via successive setAttribute calls. I'd prefer that
the attribute bag be handled like markup attributes, where xmlns
attributes are handled early so that later attributes fall into the
correct namespace.
Is there a reason to support namespaced attributes at all? They are
extremely rare, especially on the web.
Ideally I'd like to deprecate them, but I suspect that's not doable.
But I see no reason to support them in new APIs.
Isn't basic support cheap to get? Just allow the Clark notation
({ns}local) for the attribute name.
Best regards, Julian
Re: Element.create(): a proposal for more convenient element creation
On Mon, Aug 8, 2011 at 2:17 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 2011-08-08 10:17, Jonas Sicking wrote:
On Mon, Aug 8, 2011 at 12:52 AM, Tab Atkins Jr.jackalm...@gmail.com
wrote:
On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooneydomin...@google.com
wrote:
Third, is the order of attributes significant for XML namespace
declarations? eg does this:
x xmlns:foo=… foo:bar=… /
mean the same thing as
x foo:bar=… xmlns:foo=… /
? If not, including namespaces in the attribute dictionary is fraught,
because the iteration order of properties is undefined.
The order is unimportant when setting them via markup, but important
when setting them via successive setAttribute calls. I'd prefer that
the attribute bag be handled like markup attributes, where xmlns
attributes are handled early so that later attributes fall into the
correct namespace.
Is there a reason to support namespaced attributes at all? They are
extremely rare, especially on the web.
Ideally I'd like to deprecate them, but I suspect that's not doable.
But I see no reason to support them in new APIs.
Isn't basic support cheap to get? Just allow the Clark notation
({ns}local) for the attribute name.
First off, that's infinitely more work to support a rarely used
feature than not supporting it at all.
Second, since that notation isn't used anywhere else, it's a pretty
big cost in brain print for users.
So no, I wouldn't say it's cheap.
/ Jonas
Re: Reference to the HTML specification
On Fri, Aug 5, 2011 at 7:43 PM, Charles Pritchard ch...@jumis.com wrote: On 8/5/2011 9:23 AM, Marcos Caceres wrote: It should be left to the editor's (or working group) discretion as to which spec they cite regardless of the reason. And one of the role of the W3C staff is to ensure proper coordination between the various Working Groups at the W3C. I'm pointing out we are being inconsistent, I'm still not sure what the problem is. It seems like the problem is that some people feel the citing a WHATWG spec is disrespectful of the HTML WG. I think we should get on with making the best possible technology for our fellow humans and not get so caught up with who is There have been chair decisions which the WHATWG does not follow, many of them having to do with accessibility requirements. By continuing to link to the WHATWG spec as a primary source, during such fractures in consensus, it undermines the decision processes of the w3c. I thought that the WHATWG is an independent consortium; if so, it has no obligation to follow any decisions made by the HTML-WG. -- Marcos Caceres http://datadriven.com.au
Re: Element.create(): a proposal for more convenient element creation
On 2011-08-08 11:34, Jonas Sicking wrote: ... First off, that's infinitely more work to support a rarely used feature than not supporting it at all. Second, since that notation isn't used anywhere else, it's a pretty big cost in brain print for users. So no, I wouldn't say it's cheap. ... Well, it's cheap in that it needs no new API signature and uses a notation that is already well-established. Best regards, Julian
Re: Element.create(): a proposal for more convenient element creation
On Mon, Aug 8, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote: Is there a reason to support namespaced attributes at all? They are extremely rare, especially on the web. Ideally I'd like to deprecate them, but I suspect that's not doable. But I see no reason to support them in new APIs. SVG requires namespaced attributes for xlink, at least. We're planning to get rid of that in SVG2, but for now it would be necessary. We could, of course, just say Too bad, don't write things that need the xlink namespace, and wait for SVG2 to get rid of them. I don't think this would be very bad. ~TJ
Re: Element.create(): a proposal for more convenient element creation
On Mon, Aug 8, 2011 at 9:17 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Aug 8, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote: Is there a reason to support namespaced attributes at all? They are extremely rare, especially on the web. Ideally I'd like to deprecate them, but I suspect that's not doable. But I see no reason to support them in new APIs. SVG requires namespaced attributes for xlink, at least. We're planning to get rid of that in SVG2, but for now it would be necessary. We could, of course, just say Too bad, don't write things that need the xlink namespace, and wait for SVG2 to get rid of them. I don't think this would be very bad. Yup, that's my take on it. It's easy enough for people to write two lines of code instead of one for now. / Jonas
[Bug 13232] I think the section on DedicatedWorkerScope should include information about the kinds of data that postMessage can send to a worker, and the kinds of data that a worker can send back.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13232 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 20:10:13 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13255] When I use importScripts in my worker to load a separate library file, it works, but I get the error: ReferenceError: Can't find variable: importScripts (Safari) Uncaught ReferenceErr
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13255 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||INVALID --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 20:11:18 UTC --- Can't do much without a test case showing the problem. -- 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: [whatwg] File API Streaming Blobs
Sorry about the very slow response; I've been on leave, and am now catching up on my email. On Wed, Jun 22, 2011 at 11:54 AM, Arun Ranganathan a...@mozilla.com wrote: Greetings Adam, Ian, I wish I knew that earlier when I originally posted the idea, there was lots of discussion and good ideas but then it suddenly dropped of the face of the earth. Essentially I am fowarding this suggestion to public-webapps@w3.org on the basis as apparently most discussion of File API specs happen there, and would like to know how to move forward with this suggestion. The original suggestion and following comments are on the whatwg list archive, starting with http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029973.html Summing up, the problem with the current implementation of Blobs is that once a URI has been generated for them, by design changes are no longer reflected in the object URL. In a streaming scenario, this is not what is needed, rather a long-living Blob that can be appended is needed and 'streamed' to other parts of the browser, e.g. thevideo oraudio element. The original use case was: make an application which will download media files from a server and cache them locally, as well as playing them without making the user wait for the entire file to be downloaded, converted to a blob, then saved and played, however such an API covers many other use cases such as on-the-fly on-device decryption of streamed media content (ie live streams either without end or static large files that to download completely would be a waste when only the first couple of seconds need to be buffered and decrypted before playback can begin) Some suggestions were to modify or create a new type of Blob, the StreamingBlob which can be changed without its object url changing and appended to as new data is downloaded or decoded, and using a similar process to how large files may start to be decoded/played by a browser before they are fully downloaded. Other suggestions suggested using a pull API on the Blob so browsers can request for new data asynchronously, such as in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html Some problems however that a browser may face is what to do with urls which are opened twice, and whether the object url should start from the beginning (which would be needed for decoding encrypted, on-demand audio) or start from the end (similar to `tail`, for live streaming events that need decryption, etc.). Thanks, P.S. Sorry if I've not done this the right way by forwarding like this, I'm not usually active on mailing lists. I actually think moving to a streaming mode for file reads in general is desirable, but I'm not entirely sure extending Blobs is the way to go for *that* use case, which honestly is the main use case I'm interested in. We may improve upon ideas after this API goes to Last Call for streaming file reads; hopefully we'll do a better job than other non-JavaScript APIs out there :) [1]. Blob objects as they are currently specified live in memory and represent in memory File objects as well. A change to the underlying file isn't captured in the Blob snapshot; moreover, if the file moves or is no longer present at time of read, an error event is fired while processing a read operation. The object URL may be dereferenced, but will result in a 404. The Streaming API explored by WHATWG uses the Object URL scheme for videoconferencing use cases [2], and so the scheme itself is suitable for resources that are more dynamic than memory-resident Blob objects. Segment-plays/segment dereferencing in general can be handled through media fragments; the scheme can naturally be accompanied by fragment identifiers. I agree that it may be desirable to extend Blobs to do a few other things in general, maybe independent of better file reads. You've Cc'd the right listserv :) I'd be interested in what Eric has to say, since BlobBuilder evolves under his watch. Having reviewed the threads, I'm not absolutely sure that we want to add this stuff to Blob. It seems like streaming is quite a bit different than a lot of the problems people want to solve with Blobs, and we may end up with a bit of a mess if we mash them together. BlobBuilder does seem a decent match as a StreamBuilder, though. Since Blobs are specifically non-mutable, it sounds like what you're looking for is more like createObjectURL(blobBuilder) than createObjectURL(blobBuildler.getBlob()). From the threads and from my head, here are some questions: 1) Would reading from a stream always start at the beginning, or would it start at the current point [e.g. in a live video stream]? 2) Would this have to support infinite streams? 3) Would we be expected to keep around data from the very beginning of a stream, even if e.g. it's a live broadcast and you're now watching hour 7? If not, who controls the buffer size and what's the API for
[Bug 13373] Privacy: Limit SharedWorker connections to same top-level domain
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 20:23:40 UTC --- How would this protect user privacy? What's the expected leak here? As far as I can tell, SharedWorkers do not introduce a communication channel that isn't already possible with any number of other features, e.g. IndexDB, Web Storage, XHR, cookies, fingerprinting, walking Window hierarchies, etc. In any case, it's up to the UA to define the scope of user agent â so long as two frames aren't in the same unit of related browsing contexts, there's not much the spec can say that would force the UA to treat the two frames as related. Just make sure they really are separate and can never communicate, and you're fine. (Of course, if they can communicate â e.g. by passing ports along a chain of shared workers and iframes each step of which is allowed, even thought the first and last participants are blocked from seeing each other normally â then that's non-conforming.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13426] Attempt to fetch each resource identified by the resulting absolute URLs, from the entry script's origin â this makes it sound as if you should only fetch URLs frm that origin, which
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13426 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 20:33:27 UTC --- Any suggestions on how to fix this wording? This same terminology is used throughout the specification. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13526] One distinction we have decided to draw is to prevent downgrading mixed content with websockets (i.e. you cannot connect to a ws:// url from a https:// based context). -- http://www.i
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13526 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED Summary|One distinction we have|One distinction we have |decided to draw is to |decided to draw is to |prevent downgrading mixed |prevent downgrading mixed |content with websockets |content with websockets |(i.e. you cannot connect to |(i.e. you cannot connect to |a ws:// url from a https:// |a ws:// url from a https:// |based context). -- |based context). -- |http://www.ietf.org/mail-ar |http://www.ietf.org/mail-ar |chive/web/hybi/current/msg0 |chive/web/hybi/current/msg0 |8017.html - specify this if |8017.html - specify this if --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:02:22 UTC --- I guess we can try this. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13580] web workers postMessage
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13580 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WORKSFORME --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:03:10 UTC --- I added a tutorial section. Let me know if it's solved the problem. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13525] Define what .origin should be for message events
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13525 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:16:39 UTC --- http://www.whatwg.org/specs/web-apps/current-work/complete.html#messageevent defines the default as being the empty string, yes. What origin would you want it set to? Web Sockets by definition are same-origin with whatever script created them (they don't connect successfully otherwise). I suppose we could parse WebSocket.url and set MessageEvent.origin to the scheme, host, and port parts of that URL, but that seems a bit awkward (and wouldn't really be an origin in the technical sense). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13295] The make disappear a WebSocket object case should not fail the WebSocket connection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:24:49 UTC --- By the time you are to make disappear a WebSocket object, no events are going to fire ever again for that WebSocket object â the entire event queue for the Document is about to be cleared. So the only difference here is at the protocol level, and even there, there is essentially no difference â in fact the only difference is that fail says that the UA may report a problem, as you quote. But then the UA is always allowed to do that. That's just UI. So anyway, I don't understand what difference this would ever make. I've left the spec as is. The requirements on user agents are identical. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13686] Either remove the special case from onmessage (to call start()) or add it also to addEventListener listeners
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13686 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #6 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:26:24 UTC --- It makes sense to have onmessage be magical because you can only ever hook one event listener using an event handler attribute, and if you are hooking one event listener, requiring you to start() the queue immediately as well is just extra boilerplate. The common case should be simple. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13525] Define what .origin should be for message events
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13525 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Resolution|NEEDSINFO |FIXED --- Comment #4 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:41:12 UTC --- We talked about this on IRC. I'll do what EventSource does (it also doesn't use what is technically the origin, but this is mostly a matter of how you view things and if it'll help authors, why not expose it). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13322] Add UDP! Quake uses UDP, I can't continue development of WebQuake because it uses UDP.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13322 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #5 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:44:38 UTC --- Then no, intentionally. We don't want to allow hostile authors to write Web pages that can connect to servers that aren't explicitly expecting it. For example, SMTP servers (hello spam) or IRC servers or whatnot. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13588] [web messaging] Erroneous origin check in algorithm
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13588 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||INVALID --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-08 21:47:02 UTC --- Marking INVALID per http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0560.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: [whatwg] File API Streaming Blobs
It's actually confidential company data, I was thinking off. Together with the DOMCrypt API I thought this could be a valid use case. But I think there might be more cases in which it might make sense to preprocess locally stored video data. Kind regards, Simon Heckmann Am 08.08.2011 um 23:51 schrieb Glenn Maynard gl...@zewt.org: On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann si...@simonheckmann.de wrote: Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Assuming you're thinking of DRM, are there any related use cases other than crypto? Encryption for DRM, at least, isn't a very compelling use case; client-side Javascript encryption is a very weak level of protection (putting aside, for now, the question of whether the web can or should be attempting to handle DRM in the first place). If it's not DRM you're thinking of, can you clarify? -- Glenn Maynard
Re: [whatwg] File API Streaming Blobs
Sorry to jump in the middle of your discussion but after reading Eric's questions e.g. I haven't fully absorbed the MediaStream API, but perhaps it would be more natural to make a connector in that API rather than modifying Blob? I think this use case also applies for other stream/file/blob analysis and processing e.g. Augmented Reality, Object Recognition, DSP, etc. I've raised this recently across the related groups [1] with a simple use case and a number of supporting requirements. roBman [1] http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0170.html On Mon, 2011-08-08 at 23:59 +0200, Simon Heckmann wrote: It's actually confidential company data, I was thinking off. Together with the DOMCrypt API I thought this could be a valid use case. But I think there might be more cases in which it might make sense to preprocess locally stored video data. Kind regards, Simon Heckmann Am 08.08.2011 um 23:51 schrieb Glenn Maynard gl...@zewt.org: On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann si...@simonheckmann.de wrote: Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Assuming you're thinking of DRM, are there any related use cases other than crypto? Encryption for DRM, at least, isn't a very compelling use case; client-side Javascript encryption is a very weak level of protection (putting aside, for now, the question of whether the web can or should be attempting to handle DRM in the first place). If it's not DRM you're thinking of, can you clarify? -- Glenn Maynard
[XHR] support for streaming data
Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with streaming data. Using .responseType=text you can read the contents of the data as soon as it comes in, i.e. you don't have to wait for the load event to read the data. However you can't do the same for .responseType = arraybuffer. This is with good reason as arraybuffers are immutable in size and you can't really know how much data you'll receive up front. (You can make guesses based on the content-length header, but it's not always there, and isn't always reliable even when it's there). Another problem is that even if the webpage is able use .responseType=text and consume the data in an incremental manner, the UA still ends up accumulating and holding large chunks of data in memory. So in other words, the use case is pages that are able to incrementally consume binary and textual data and wanting to do so without having to wait until the whole resource has been downloaded, and do so without requiring the UA to hold large amount of data in memory. To solve this I propose we add two new values to .responseType: streaming-text and streaming-arraybuffer. When .responseType is set to streaming-text then during each progress event, .response would be set to the text that was received since the last progress event (and since the loadstart event for the first progress event). Same thing when .responseType is set to streaming-arraybuffer. In this case .response is set to an ArrayBuffer containing the data received since the last progress event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a progress event, but instead just a load event. This means that people will have to consume data both from the progress event and from the load event. Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. / Jonas
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 8:13 PM, Jonas Sicking jo...@sicking.cc wrote: Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0993.html -- Glenn Maynard
Re: [XHR] support for streaming data
On 8/8/2011 5:13 PM, Jonas Sicking wrote: Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with streaming data. ... Agreed. I proposed something similar in January, with fixed buffer lengths: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html Fixed buffers are somewhat common with more data intense network processing. They may trigger quite a few more progress events, but they guarantee an upper size in memory usage / array length. ... Same thing when .responseType is set to streaming-arraybuffer. In this case .response is set to an ArrayBuffer containing the data received since the last progress event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a progress event, but instead just a load event. This means that people will have to consume data both from the progress event and from the load event. Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. I agree to this, too. For a stream, load may be the same thing as stop, and not have result data. Anne suggested using EventSource and other WebSockets style semantics instead of overloading XHR2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html I'd be happy-enough just having a streaming binary buffer. -Charles
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 5:48 PM, Charles Pritchard ch...@jumis.com wrote: On 8/8/2011 5:13 PM, Jonas Sicking wrote: Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with streaming data. ... Agreed. I proposed something similar in January, with fixed buffer lengths: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html Fixed buffers are somewhat common with more data intense network processing. They may trigger quite a few more progress events, but they guarantee an upper size in memory usage / array length. ... Same thing when .responseType is set to streaming-arraybuffer. In this case .response is set to an ArrayBuffer containing the data received since the last progress event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a progress event, but instead just a load event. This means that people will have to consume data both from the progress event and from the load event. Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. I agree to this, too. For a stream, load may be the same thing as stop, and not have result data. Anne suggested using EventSource and other WebSockets style semantics instead of overloading XHR2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html I'd be happy-enough just having a streaming binary buffer. Unless EventSource is dramatically changed, it won't solve the use cases here. One use case that I've brought up several times in the past is incremental loading of Word documents. A more current example would be loading a pdf document and rendering it incrementally as data is coming in. Neither of these cases is even close to how EventSource currently works, so I don't think it's a good fit. / Jonas
Re: [whatwg] File API Streaming Blobs
On 8/8/2011 2:51 PM, Glenn Maynard wrote: On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann si...@simonheckmann.de mailto:si...@simonheckmann.de wrote: Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Assuming you're thinking of DRM, are there any related use cases other than crypto? Encryption for DRM, at least, isn't a very compelling use case; client-side Javascript encryption is a very weak level of protection (putting aside, for now, the question of whether the web can or should be attempting to handle DRM in the first place). If it's not DRM you're thinking of, can you clarify? Jonas Sickling brought up a few cases for XHR-based streaming of arraybuffers: progressive rendering of word docs and PDFs. WebP and WebM have had interesting packaging hacks. Packaging itself, whether DRM or not, is compelling. PDF supports embedded data, a wide range of formats. GPAC provides many related tools (MP4 based, I believe): http://gpac.wp.institut-telecom.fr/ The audio and video tags drop frames It seems to me that if a listener is not registered to the stream, data would just be dropped. As an alternative, the author could register a fixed length circular buffer. For instance, I could create 1 megabyte arrayview, run URL.createBlobStream(ArrayView) and use .append(data). That kind of structure may support multicast (multiple audio/video elements) and improved XHR2 semantics. The circular buffer, itself, is easy to prototype: subarray works well with typed arrays. Otherwise relevant, is the work on raw audio data that Firefox and Chromium have released as experimental extensions. It does work on a buffer-based system. -Charles
Re: [XHR] support for streaming data
On 8/8/2011 5:59 PM, Jonas Sicking wrote: On Mon, Aug 8, 2011 at 5:48 PM, Charles Pritchardch...@jumis.com wrote: On 8/8/2011 5:13 PM, Jonas Sicking wrote: Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with streaming data. ... Agreed. I proposed something similar in January, with fixed buffer lengths: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html Fixed buffers are somewhat common with more data intense network processing. They may trigger quite a few more progress events, but they guarantee an upper size in memory usage / array length. ... Same thing when .responseType is set to streaming-arraybuffer. In this case .response is set to an ArrayBuffer containing the data received since the last progress event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a progress event, but instead just a load event. This means that people will have to consume data both from the progress event and from the load event. Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. I agree to this, too. For a stream, load may be the same thing as stop, and not have result data. Anne suggested using EventSource and other WebSockets style semantics instead of overloading XHR2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html I'd be happy-enough just having a streaming binary buffer. Unless EventSource is dramatically changed, it won't solve the use cases here. One use case that I've brought up several times in the past is incremental loading of Word documents. A more current example would be loading a pdf document and rendering it incrementally as data is coming in. Neither of these cases is even close to how EventSource currently works, so I don't think it's a good fit. Incremental rendering of formats that support it, is certainly a good case. PDF itself, is more complex than Word: Supporting PDF viewer requires HTTP Content-Range to handle offsets in large streams. For efficient PDF support, I'd want to work with something like this: e.response.length == size of data in bytes (array buffer may be larger) e.response.data == array buffer e.response.seek() - method to seek ahead N-bytes before next progress event. Here's a related on File API Streaming Blobs -- this is a valid use case other than crypto, I've posted as su: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0725.html I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. It seems that a buffer less than 16K could be advantageous on Linux: http://blog.superpat.com/2010/06/01/zero-copy-in-linux-with-sendfile-and-splice/ That'd be helpful for local file viewing, if nothing else. For some authors, it may be helpful to specify the length they're looking to have filled at any one time. -Charles
Re: [XHR] support for streaming data
On 8/8/11 5:13 PM, Jonas Sicking wrote: To solve this I propose we add two new values to .responseType: streaming-text and streaming-arraybuffer. I think this would be a very useful feature. I only have naming nits: 1) What do you think of textstream instead of streaming-text? Similarly for arraybufferstream (or ArrayBufferStream) 2) Is there any possible use case for streaming blobs? If so, then I'd say that the streaming vs. non-streaming issue is orthogonal to the data type issue and there should be something like responseMethod = stream instead of responseType = streaming-text 3) What you propose isn't exactly what I think of as streaming, since there isn't a FIFO buffer involved. I can't get a progress event, read a few bytes of the response and then leave the rest to process at the load event, can I? In this proposal we get one chunk of data per progress event, and that data will be gone when the next progress event arrives, right? Would names like ChunkedText and ChunkedArrayBuffer more accurately reflect what is going on? Or, if Chunked would incorrectly imply some relationship to HTTP chunked encoding, how about TextFragments and ArrayBufferFragments When .responseType is set to streaming-text then during each progress event, .response would be set to the text that was received since the last progress event (and since the loadstart event for the first progress event). Same thing when .responseType is set to streaming-arraybuffer. In this case .response is set to an ArrayBuffer containing the data received since the last progress event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a progress event, but instead just a load event. This means that people will have to consume data both from the progress event and from the load event. Another solution would to make sure to always fire a progress event for the last data before firing the load event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. It seems like it would be important for browsers to do that for these responseTypes, even if they didn't do it for regular text and arraybuffer responses. / Jonas David
