Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after the
postMessage call.
Everything work. No throw is done and B isn't gutted because it isn't
transferrable.
Throwing for unsupported objects will break common, reasonable uses, making
everyone jump hoops to use transfer. Not throwing will only break code that
seriously misuses the API, by listing objects for transfer and then
continuing to use the object.
Anyway, if this exception is thrown, everyone's going to use a helper like
this:
function filterTransferrable(list) {
var ret = [];
for(var i = 0; i list.length; ++i) {
if(list[i] instanceof Transferrable)
ret.push(list[i]);
}
return ret;
}
postMessage([A, B], filterTransferrable([A, B]));
... which will trigger the case you describe anyway.
--
Glenn Maynard
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote: Let's say the call doesn't throw when given a type B that isn't transferrable. Let's also say some later changes the javascript code and uses B after the postMessage call. Everything work. No throw is done and B isn't gutted because it isn't transferrable. Throwing for unsupported objects will break common, reasonable uses, making everyone jump hoops to use transfer. Not throwing will only break code that seriously misuses the API, by listing objects for transfer and then continuing to use the object. Code always seriously misuses apis. See Raymond Chen's blog for numerous examples if you have any doubt (http://blogs.msdn.com/b/oldnewthing/).
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 3:14 AM, David Levin le...@chromium.org wrote: On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote: Let's say the call doesn't throw when given a type B that isn't transferrable. Let's also say some later changes the javascript code and uses B after the postMessage call. Everything work. No throw is done and B isn't gutted because it isn't transferrable. Throwing for unsupported objects will break common, reasonable uses, making everyone jump hoops to use transfer. Not throwing will only break code that seriously misuses the API, by listing objects for transfer and then continuing to use the object. Code always seriously misuses apis. See Raymond Chen's blog for numerous examples if you have any doubt (http://blogs.msdn.com/b/oldnewthing/). You didn't respond to the rest of my mail, where I pointed out that the misuse case will end up broken anyway as everyone will likely use a wrapper to get the no-exception behavior. You'd have to, to support older browsers which don't support transfer for as many types. Making people use a helper function like that is just making them jump an unnecessary hoop. -- Glenn Maynard
Re: [widgets] WARP and redirects
On 6/20/11 12:57 PM, Robin Berjon wrote: On Jun 20, 2011, at 12:23 , Marcos Caceres wrote: On Mon, Jun 20, 2011 at 11:41 AM, Robin Berjonrobin.ber...@gmail.com wrote: You have origin restrictions in place. If you XHR to perfectly-legit.com and it redirects to something protected inside your network, unless you've used CORS to open up the latter (in which case you're begging to get hurt) then you won't get anything. The use case I was thinking about more centered around images, scripts, and iframes, which are not really subject to CORS (though I can see how they could be). Anyway, we already have origin=*, so probably doesn't matter too much at this point.
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 12:26 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 3:14 AM, David Levin le...@chromium.org wrote: On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote: Let's say the call doesn't throw when given a type B that isn't transferrable. Let's also say some later changes the javascript code and uses B after the postMessage call. Everything work. No throw is done and B isn't gutted because it isn't transferrable. Throwing for unsupported objects will break common, reasonable uses, making everyone jump hoops to use transfer. Not throwing will only break code that seriously misuses the API, by listing objects for transfer and then continuing to use the object. Code always seriously misuses apis. See Raymond Chen's blog for numerous examples if you have any doubt (http://blogs.msdn.com/b/oldnewthing/). You didn't respond to the rest of my mail, where I pointed out that the misuse case will end up broken anyway as everyone will likely use a wrapper to get the no-exception behavior. You'd have to, to support older browsers which don't support transfer for as many types. If you insist Making people use a helper function like that is just making them jump an unnecessary hoop. It makes them jump through another hoop to potentially misuse the api. It shouldn't be simple to misuse apis. Also, I haven't seen mention of Transferrable else where in the final proposed solution which you used in that code. dave
Re: Mouse Lock
On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 1:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: A model which I suggested privately, and which I believe others have suggested publicly, is this: 1. While fullscreen is enabled, you can lock the mouse to the fullscreened element without a prompt or persistent message. A temporary message may still be shown. The lock is automatically released if the user exits fullscreen. 2. During a user-initiated click, you can lock the mouse to the target or an ancestor without a permissions prompt, but with a persistent message, either as an overlay or in the browser's chrome. 3. Otherwise, any attempt to lock the mouse triggers a permissions prompt, and while the lock is active a persistent message is shown. There's a middle ground here: you can lock the mouse to the window, but not completely. That is, if the user moves the mouse to the edge, it remains inside, but if they move it fast enough it escapes. This is enough to stop the window from accidentally losing focus when you're trying to click on something near the edge of the screen, but it lets you easily get outside the window if you actually want to. IIRC, Wine does this in windowed mode. Of course, it might not be suitable for games that want to hide the cursor, like FPSes, but it might be a possible fallback if the browser doesn't trust the site enough for whatever reason to let it fully lock the mouse. This seems weird. When would you use this middle ground? Would users understand it? Also, as you say, totally inappropriate for FPS games. -- Simon Pieters Opera Software
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote: Making people use a helper function like that is just making them jump an unnecessary hoop. It makes them jump through another hoop to potentially misuse the api. No, it's another hoop that *everyone* has to jump through to use the API at all, so code you write in browser N+1 would also work in browser N where fewer classes support transfer. Jumping that hoop is not the misuse; it's a direct requirement of the API. *Because* everyone would be doing that, the misuse will also be possible. Also, I haven't seen mention of Transferrable else where in the final proposed solution which you used in that code. It's an interface to indicate that an object is transferrable, to allows feature testing. http://krijnhoetmer.nl/irc-logs/whatwg/20110617#l-1427 -- Glenn Maynard
Testing Progress Events and CR
Since this relates to the CR of Progress Events I thought I would bring it up on this list instead of one of the testing mailing lists. Progress Events depends a lot on other specifications. Basically the only thing that can be tested is creating synthetic events and seeing whether the interface is correct. And synthetic events is an aspect that might need changing given the new way of creating them we are going to introduce in DOM Core. So a) maybe we should hold off on going to CR until the new way of initializing events is settled in DOM Core and b) we should probably modify the CR exit criteria somewhat to make clear what we expect to be able to test. Progress Events can be more fully tested in the context of another specification, e.g. the File API or XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
[cors] Content-Type
Currently when making a preflight request user agents are required to include content-type in the Access-Control-Request-Headers header if the author specified a Content-Type header. However, this Content-Type header included in the actual request can contain a header value allowed by simple headers, such as text/plain. Is it a problem that the server cannot distinguish which Content-Type header is meant? The primary reason for the preflight request is awareness, but it still strikes me as icky. There is one other problem noted by sicking on the WHATWG list. Namely that Content-Type can also be set by the user agent. E.g. based on the File object passed to the send() method in XMLHttpRequest. So I think I will update the places where CORS compares author request headers (I renamed custom request headers as author is clearer and custom caused confusion) against simple headers to also compare the Content-Type header (if set by the user agent) against simple headers. Does that make sense? -- Anne van Kesteren http://annevankesteren.nl/
Re: Testing Progress Events and CR
On Jun/22/2011 6:28 AM, ext Anne van Kesteren wrote: Since this relates to the CR of Progress Events I thought I would bring it up on this list instead of one of the testing mailing lists. Progress Events depends a lot on other specifications. Basically the only thing that can be tested is creating synthetic events and seeing whether the interface is correct. And synthetic events is an aspect that might need changing given the new way of creating them we are going to introduce in DOM Core. So a) maybe we should hold off on going to CR until the new way of initializing events is settled in DOM Core What is the approximate time frame for that? and b) we should probably modify the CR exit criteria somewhat to make clear what we expect to be able to test. What specific change do you propose? -AB
Re: [cors] Content-Type
On 2011-06-22 14:44, Anne van Kesteren wrote: Currently when making a preflight request user agents are required to include content-type in the Access-Control-Request-Headers header if the author specified a Content-Type header. However, this Content-Type header included in the actual request can contain a header value allowed by simple headers, such as text/plain. Is it a problem that the server cannot distinguish which Content-Type header is meant? The primary reason for the preflight request is awareness, but it still strikes me as icky. ... I just had a quick look at the spec, and couldn't find an example message flow; it would be very helpful to see one. Best regards, Julian
Re: Mouse Lock
On Wed, Jun 22, 2011 at 2:54 AM, Glenn Maynard gl...@zewt.org wrote: Unrelated, another detail: if most implementations are going to need to warp the mouse cursor to do this, the other mouse event coordinates should always be 0 (or null). Otherwise, implementations on platforms which don't need to warp the cursor may still fill these in, causing incompatibilities. Events like mouseover should probably be suppressed, too. At that point, it's probably cleaner to stop firing *all* mouse movement events entirely, as if the mouse isn't moving, and to use a separate mousedelta event when locked which only has deltaX and deltaY. I had this thought initially, but didn't pursue it. Now that you bring it up again, though, I think I agree. ~TJ
Re: Mouse Lock
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: 2. During a user-initiated click, you can lock the mouse to the target or an ancestor without a permissions prompt, but with a persistent message, either as an overlay or in the browser's chrome. Does this mean that website is forced to release the lock before mouse-up happens? Or did you just mean that a website can start the lock during a click? If it's latter, I have a problem with that. I know many people who select text on a page just to read them. They obviously don't expect their cursors being tracked/locked by a website. Also, once my mouse is locked, how do I free it? - Ryosuke
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote: Making people use a helper function like that is just making them jump an unnecessary hoop. It makes them jump through another hoop to potentially misuse the api. No, it's another hoop that *everyone* has to jump through to use the API at all, so code you write in browser N+1 would also work in browser N where fewer classes support transfer. I do understand Glenn's point about convenience, but I generally strongly prefer APIs that throw exceptions when passed unsupported arguments over APIs that silently ignore those arguments.
Re: Mouse Lock
On Wed, Jun 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: 2. During a user-initiated click, you can lock the mouse to the target or an ancestor without a permissions prompt, but with a persistent message, either as an overlay or in the browser's chrome. Does this mean that website is forced to release the lock before mouse-up happens? Or did you just mean that a website can start the lock during a click? The latter; the former is useful, but in a different way (it's for letting people drag something, like a scrollbar, without having to stay precisely on the element). If it's latter, I have a problem with that. I know many people who select text on a page just to read them. They obviously don't expect their cursors being tracked/locked by a website. We can't do anything about cursors being tracked - that's allowed already by the existing mouse events. I don't expect authors to lock the mouse arbitrarily with this ability unless they're being malicious. The intent is to allow non-fullscreen games to lock the mouse when the user clicks the Start Game button or similar. (For the malicious authors, see below.) Also, once my mouse is locked, how do I free it? That was covered in the paragraph you quoted, though cursorily. If the mouse is locked in this way, the browser should show a persistent message (either in its chrome or as an overlay) saying something like Your mouse cursor is being hidden by the webpage. Press Esc to show the cursor.. This shouldn't be too annoying for the games case, but should allow users, even clueless ones, to know when a site is being malicious and how to fix it. Once they get their cursor back, they can just leave that page. ~TJ
Re: Mouse Lock
On Wed, Jun 22, 2011 at 8:27 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 22, 2011 at 8:17 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Also, once my mouse is locked, how do I free it? That was covered in the paragraph you quoted, though cursorily. If the mouse is locked in this way, the browser should show a persistent message (either in its chrome or as an overlay) saying something like Your mouse cursor is being hidden by the webpage. Press Esc to show the cursor.. This shouldn't be too annoying for the games case, but should allow users, even clueless ones, to know when a site is being malicious and how to fix it. Once they get their cursor back, they can just leave that page. This might just be a UI problem but I can assure you many users won't be able to find such a message or won't be able to understand what it means. e.g. I know quite few people who don't know what mouse cursor or Esc is. I have trapped your mouse cursor in this box: [picture of mouse cursor]. ...that would actually be pretty funny. Someone should do that. ~TJ
Re: Mouse Lock
On 06/22/2011 06:17 PM, Tab Atkins Jr. wrote: On Wed, Jun 22, 2011 at 8:02 AM, Ryosuke Niwarn...@webkit.org wrote: On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: 2. During a user-initiated click, you can lock the mouse to the target or an ancestor without a permissions prompt, but with a persistent message, either as an overlay or in the browser's chrome. Does this mean that website is forced to release the lock before mouse-up happens? Or did you just mean that a website can start the lock during a click? The latter; the former is useful, but in a different way (it's for letting people drag something, like a scrollbar, without having to stay precisely on the element). If it's latter, I have a problem with that. I know many people who select text on a page just to read them. They obviously don't expect their cursors being tracked/locked by a website. We can't do anything about cursors being tracked - that's allowed already by the existing mouse events. How? If mouse is not pressed and you move mouse outside the browser window, the mouse sure can't be tracked. I don't expect authors to lock the mouse arbitrarily with this ability unless they're being malicious. And we need to protect user from malicious web apps. The intent is to allow non-fullscreen games to lock the mouse when the user clicks the Start Game button or similar. (For the malicious authors, see below.) Also, once my mouse is locked, how do I free it? That was covered in the paragraph you quoted, though cursorily. If the mouse is locked in this way, the browser should show a persistent message (either in its chrome or as an overlay) saying something like Your mouse cursor is being hidden by the webpage. Press Esc to show the cursor.. This shouldn't be too annoying for the games case, but should allow users, even clueless ones, to know when a site is being malicious and how to fix it. Once they get their cursor back, they can just leave that page. So we would end up web apps where after clicking anything in the page user needs to use keyboard to get out of the application? Doesn't sound too user friendly. IMO, user really should be informed before locking the mouse. -Olli
Re: Testing Progress Events and CR
On Wed, 22 Jun 2011 15:44:36 +0200, Arthur Barstow art.bars...@nokia.com wrote: On Jun/22/2011 6:28 AM, ext Anne van Kesteren wrote: So a) maybe we should hold off on going to CR until the new way of initializing events is settled in DOM Core What is the approximate time frame for that? I just checked in the proposal https://bitbucket.org/ms2ger/dom-core/changeset/b9bb17789db9 into DOM Core but I suspect it needs some refining and reviewing. I suspect we need another Progress Events LC for this as technically it is a new feature :/ and b) we should probably modify the CR exit criteria somewhat to make clear what we expect to be able to test. What specific change do you propose? Actually, the current text seems fine as is. Sorry! -- Anne van Kesteren http://annevankesteren.nl/
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote: Making people use a helper function like that is just making them jump an unnecessary hoop. It makes them jump through another hoop to potentially misuse the api. No, it's another hoop that *everyone* has to jump through to use the API at all, so code you write in browser N+1 would also work in browser N where fewer classes support transfer. Jumping that hoop is not the misuse; it's a direct requirement of the API. *Because* everyone would be doing that, the misuse will also be possible. The throwing aspect is a useful debugging tool to warn developers about misuse that they wouldn't be aware of otherwise. (Not everyone will read the spec as closely as you do -- may will just write code to get the job done and declare it done when it works -- a not throwing api may still be fast but will be deceptive in allowing parameters and not acting on them leading to the discussed misuse by accident -- it happens all the time by people who are trying to be careful even.) Your given code isn't the only possible solution. However, it is one that imposes M choose N combinations for the code resulting in lots of testing combinations. I could easily envision several alternatives to your snippet which could be written which would be better. For example, one could write code that either send all parameters using fast path or none. (This is only two test cases and they could have a debug switch to make everything be passed in the fast method to ensue that it worked correctly -- note this isn't possible if the api doesn't throw.) I'm fairly certain that we won't agree. Due to my many experiences with people including myself misusing apis and not realizing it, I strongly prefer an api that warns of misuse. You don't. I see either of us saying anything new so I don't plan to continue this discussion further because I believe that we have both laid our points of view in vivid detail :). best wishes, dave
Re: RfC: moving Web Storage to WG Note; deadline June 29
On Jun/20/2011 6:37 PM, ext Ian Hickson wrote: On Mon, 20 Jun 2011, Julian Reschke wrote: On 2011-06-20 13:58, Anne van Kesteren wrote: On Mon, 20 Jun 2011 13:54:12 +0200, Julian Reschke julian.resc...@gmx.de wrote: As recently discussed in the HTMLWG -- you can have Note that is normative; it's just a signal that work on this has ended. 1) You do not get patent policy protection. 2) The work has not ended if the feature is still part of the web platform. Dunno about patents. But work has ended is supposed to mean that the WG is done with it, AFAIU. We could just publish it as a REC and say we're done with it, too. Indeed, one disadvantage of moving Web Storage to a WG Note is that it would _not_ have any patent commitments. Regarding some of the process aspects of this proposal, although the decision to publish WDs and LCWDs is effectively left to the WG, the decision to publish further maturity levels requires other participants: Candidate Recommendations require Director's approval and the decision to publish a Recommendation is subject to feedback from the entire W3C Membership (WebApps includes only 24 of the 325 W3C Members). I mention this because off-list I heard a comment that suggested Storage's mutex issue conflicts with a Recommendation's requirement that the ideas in the technical report are appropriate for widespread deployment [1]. Naturally, some will disagree with this view, especially given the broad implementation of this spec. Anyhow, only a small set of participants have responded to this RfC so _I encourage others that have not responded to please submit their feedback_. -Thanks, AB [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-publication
Re: RfC: moving Web Storage to WG Note; deadline June 29
On 6/22/11 1:50 PM, Arthur Barstow wrote: Naturally, some will disagree with this view, especially given the broad implementation of this spec. But said implementations don't implement the storage mutex... -Boris
Re: Mouse Lock
John Villar and I have produced a draft specification: https://docs.google.com/document/d/1uV4uDVIe9-8XdVndW8nNGWBfqn9ieeop-5TRfScOG_o/edit?hl=en_USauthkey=CM-dw7QG Some additional notes included in that draft not yet discussed here: - .deltaX conflicts with WheelEvent, I've used .movementX/Y instead unless we feel DOM L3 should be modified. - I've omitted the call of mouselocklost at a page close or ‘onbeforeunload’, as I can not determine a use case that benefits from it. - I've omitted the suggestion of cancelLock on a bubbling MouseEvent - as it is not needed, .target.unlockMouse() can be called.
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after the
postMessage call.
Everything work. No throw is done and B isn't gutted because it isn't
transferrable.
Throwing for unsupported objects will break common, reasonable uses, making
everyone jump hoops to use transfer. Not throwing will only break code that
seriously misuses the API, by listing objects for transfer and then
continuing to use the object.
Anyway, if this exception is thrown, everyone's going to use a helper like
this:
function filterTransferrable(list) {
var ret = [];
for(var i = 0; i list.length; ++i) {
if(list[i] instanceof Transferrable)
ret.push(list[i]);
}
return ret;
}
postMessage([A, B], filterTransferrable([A, B]));
... which will trigger the case you describe anyway.
The structured cloning algorithm itself will throw an exception if it
encounters an object type it doesn't know how to handle, in particular
a host object. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#safe-passing-of-structured-data
. As browsers evolve, it will be host object types that are promoted
to transferable status. Therefore, applications that are written for
browser version N+1 which supports transferring host object type Foo
will throw an exception on browser version N when sending a Foo via
postMessage simply because of its presence in the object graph,
regardless of its presence in the transfer array.
For this reason, and because I also prefer fail-fast APIs, I agree
that unsupported objects in the transfer array should raise an
exception.
I doubt that authors will write a filter for the transferable array as
you suggest, since filtering of the object graph would be necessary
too. Rather, I think that applications will be written for browsers
that support transferring host objects of a particular type.
The current proposal sounds good to me.
-Ken
Re: [whatwg] File API Streaming Blobs
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. -- A* [1] http://download.oracle.com/javase/1.4.2/docs/api/java/io/FileInputStream.html [2] http://www.whatwg.org/specs/web-apps/current-work/#stream-api
Re: RfC: moving Web Storage to WG Note; deadline June 29
On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that there are currently major browsers that do not follow the spec as currently written and have explicitly said that they have no plans to do so. If browsers can agree on what to implement, update the spec to reflect that. If they can't and we don't think they ever will, update the spec to say behavior is undefined. Either way, it's no less worthy of REC-track specification than other preexisting features that are flawed but in practice not removable from the platform.
Re: RfC: moving Web Storage to WG Note; deadline June 29
A proposal, Le 22 juin 2011 à 13:50, Arthur Barstow a écrit : participants: Candidate Recommendations require Director's approval and the decision to publish a Recommendation is subject to feedback from the entire W3C Membership (WebApps includes only 24 of the 325 W3C Members). We usually never exit a phase but enter a phase in the W3C Process. W3C Working Draft 08 February 2011 http://www.w3.org/TR/2011/WD-webstorage-20110208/ The last Editor's Draft 21 June 2011 http://dev.w3.org/html5/webstorage/ Is there enough time, energy to produce an implementation report for the current spec features? Specifically from the people who have implemented it. Opera has a simili implementation report http://www.opera.com/docs/specs/presto29/webstorage/ with the explicit following mention Opera Presto does not currently support: Structured storage Storage mutex What about others? It will help to see if there is work needed to reduce the specification, abandon it, etc. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
[Bug 9903] Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||eliot...@microsoft.com Resolution||FIXED --- Comment #8 from Eliot Graff eliot...@microsoft.com 2011-06-22 22:13:51 UTC --- Section 3.1.3 now contains the following reference to the ECMA algorithm agreed upon in mail [1] and in comment 7. Note the second to last sentence: ]] For purposes of comparison, all Arrays are greater than all DOMString, Date and float values; all DOMString values are greater than all Date and float values; and all Date values are greater than all float values. Values of type float are compared to other float values numerically. Values of type Date are compared to other Date values chronologically. Values of type DOMString are compared to other values of type DOMString by using the algorithm defined by step 4 of section 11.8.5, The Abstract Relational Comparison Algorithm, of the ECMAScript Language Specification [ECMA-262]. Values of type Array are compared to other values of type Array as follows: [[ [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1091.html Resolving as FIXED -- 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 12607] [HTML DOM][XMLHttpRequest object] Ass property so that: Do not follow location headers
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12607 Anne ann...@opera.com changed: What|Removed |Added CC||ann...@opera.com, ||public-webapps@w3.org Component|HTML5 spec (editor: Ian |XHR 2.0 |Hickson)| AssignedTo|i...@hixie.ch|ann...@opera.com Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org --- Comment #5 from Anne ann...@opera.com 2011-06-22 22:23:03 UTC --- This is for the WebApps WG. -- 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: RfC: moving Web Storage to WG Note; deadline June 29
On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that there are currently major browsers that do not follow the spec as currently written and have explicitly said that they have no plans to do so. If browsers can agree on what to implement, update the spec to reflect that. If they can't and we don't think they ever will, update the spec to say behavior is undefined. Either way, it's no less worthy of REC-track specification than other preexisting features that are flawed but in practice not removable from the platform. I think browsers are relatively speaking closer in implementation to each other than to the spec currently. Would it be too much work to come up with a specification that did not include the structured clone algorithm and did not include the storage mutex? That seems to be what browsers need to support for compatibility, and so it would be ideal to capture that in some form. Such a specification would have inherent and unavoidable data races (as do current and future implementations), so it would be a stretch to consider it recommended, but it would reflect reality. - James
