[Bug 14848] HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: nToZIrKj/IYE0NjsLns7R+Msfcg=
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14848 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@opera.com Resolution||INVALID --- Comment #1 from Anne ann...@opera.com 2011-11-18 08:12:59 UTC --- No actual comment given. -- 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: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.comwrote: ** Does anybody use registerProtocolHandler in any real sense? Is registerContentHandler needed? It seems like Web Intents is an evolution on the concept. I don't think we're going to see convergence on those old methods. I'm ready to leave them both in favor of a yet-to-be announced candidate (web intents). URIs are better than protocols, and Intents are better than content handlers. In my opinion. RPH seems to be intended primarily for mailto: (I think that's where it is used.) I'm not sure what the RCH usage is like. It is definitely possible to imagine mapping UA handling of mailto: onto web intents. The way I think of it is like this: RPH is basically an action with a payload. RCH is essentially type info with the payload. Web Intents is kind of off-axis with both an action and a type as well as the payload. The idea (taking inspiration from the pluggable usage in the Android ecosystem) is that the action (analogous to the protocol) is a locus between the client and handling service which can be messaged to the user in a well-understood way. (i.e. instead of just saying here's some data, do whatever you want with it, which is a more content-type-driven As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent channel. It isn't clear to me as yet what to do about those. They definitely imply a more well-specified protocol to be pursued over that channel. Web Intents as an API doesn't really include or exclude that in the current form. On the other hand, it'd be a really nice application of the Web Intents permissions mechanism to be able to connect up, say, an SSH connection using Web Intents, so that I could write an in-browser terminal which could then be attached to a secure socket by the user. At this point, I'm not sure whether this kind of persistent connection use case is far enough from Web Intents to want to exclude it, or close enough to want to include it explicitly. Our early belief is that we aren't ruling it out with the proposed API, since MessageChannels could be provided or returned in the payload data. On the other hand, we haven't chosen to explicitly include such usage. But a lot of this stuff just comes with nice platform integration; I just tried passing Blob objects through intents in Chrome Tip-of-Tree with our prototype, and it Just Works, allowing a really appealing vision into what upload intents and file interactions could be like. Wins like that make me think that focusing on the sweet spot RPC interaction will not paint us into a corner. This is awesome, anything that is Serialzable is via the structured clone will work, so now we can pass File Objects between services, ImageData And MessageChannels. On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp On the earlier subject of demos, the current demos are at http://demos.webintents.org/ please note, twitpic does not work and I will be removing it from the list today until I have it working and I will be adding more over the coming days. re:Dave Ragget - the case is in one of the demos, save image, which hooks up with imgur API. There we pass the data from the client app (ImageStudio) to Imgur and the imgur service will handle the notifications to the user about the upload progress (via an XMLHttpRequest), at this point ImageStudio doesn't need to know or care about the progress of the upload, other than it completes or fails. P -Greg -- Paul Kinlan Developer Advocate @ Google for Chrome and HTML5 G+: http://plus.ly/paul.kinlan t: +447730517944 tw: @Paul_Kinlan LinkedIn: http://uk.linkedin.com/in/paulkinlan Blog: http://paul.kinlan.me Skype: paul.kinlan
Re: XHR content-type rewriting
On 2011-11-17 07:14, Julian Reschke wrote: On 2011-11-17 01:55, Boris Zbarsky wrote: On 11/17/11 2:18 AM, Julian Reschke wrote: - Opera and IE do not rewrite the type; so if the caller sets the wrong charset, this is what is sent to the server Which on the face of it is broken Absolutely. It would be less broken spec-wise if XHR stated that adding the charset in setRequestHeader is illegal. Minimally, it should recommend not to include it as it's pointless. ... Such as: Specifying the charset in the Content-Type header field is pointless because the encoding of the payload is controlled by the User Agent and hardwired to UTF-8. (as opposed to just writing the specs for the browser implementors and leaving web authors guessing) Best regards, Julian
Re: Firefox bug: Worker load ignores Content-Type version parameter
On 2011-11-18 12:36, Julian Reschke wrote: On 2011-11-18 12:29, Bjoern Hoehrmann wrote: * Anne van Kesteren wrote: On Fri, 18 Nov 2011 09:32:22 +0100, Julian Reschkejulian.resc...@gmx.de wrote: I recently started looking at FF's Content-Type related code. As far as I can tell, there are at least two code paths, one taken for the HTTP header field, one for HTML media type attributes. There may be more. The HTTP code definitively only processes the charset parameter. If Gecko does that for Workers, that would be a bug. Workers are UTF-8 only. If you are saying that Content-Type: application/javascript;charset=iso-8859-1 ... 0xC3 0xB6 ... should have U+00C3 U+00B6 when used viascript and an U+00F6 when used via `new Worker` then I will stand ready to roll over the floor laughing when Firefox and Chrome are changed so they conform to this bizarre idea instead of doing the right thing and treating the two cases the same. +1 The only alternative would be to *reject* the script. ... But it seems that this is what http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. Please consider this a bug report. Best regards, Julian
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 12:52:36 +0100, Julian Reschke julian.resc...@gmx.de wrote: If Gecko does that for Workers, that would be a bug. Workers are UTF-8 only. If you are saying that Content-Type: application/javascript;charset=iso-8859-1 ... 0xC3 0xB6 ... should have U+00C3 U+00B6 when used viascript and an U+00F6 when used via `new Worker` then I will stand ready to roll over the floor laughing when Firefox and Chrome are changed so they conform to this bizarre idea instead of doing the right thing and treating the two cases the same. +1 The only alternative would be to *reject* the script. ... But it seems that this is what http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. Please consider this a bug report. UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On 11/19/11 12:52 AM, Julian Reschke wrote: http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. For what it's worth, Gecko's worker loading code runs the same algorithm to determine the charset as the algorithm used for script src (except of course it does not have access to any charset attributes on an element). And by same algorithm I mean they call the same function in our code which takes the HTTP headers, document object, value of @charset, and bytes and returns a Unicode string. If we have UA compat on that behavior, it makes more sense to standardize it than to standardize the UTF-8-only thing, perhaps -Boris
Re: Firefox bug: Worker load ignores Content-Type version parameter
On 2011-11-18 13:03, Simon Pieters wrote: UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. What kind of server sets a charset on JS *and* cannot be configured not to? And, if this is the case, isn't this a good reason to actually require that the charset is handled correctly? I really believe that piling up workarounds and inconsistencies like these makes the whole platform much harder to use than necessary. Best regards, Julian
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:03:03 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/19/11 12:52 AM, Julian Reschke wrote: http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. For what it's worth, Gecko's worker loading code runs the same algorithm to determine the charset as the algorithm used for script src (except of course it does not have access to any charset attributes on an element). And by same algorithm I mean they call the same function in our code which takes the HTTP headers, document object, value of @charset, and bytes and returns a Unicode string. If we have UA compat on that behavior, it makes more sense to standardize it than to standardize the UTF-8-only thing, perhaps Opera conforms to the spec and always decodes worker scripts as UTF-8. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-18 13:03, Simon Pieters wrote: UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. What kind of server sets a charset on JS *and* cannot be configured not to? I don't know. I know we changed appcache to not do MIME type checking of the cache manifest because authors had trouble changing it. I know we sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and text/plain; charset=UTF-8 because it's the default in some servers. And, if this is the case, isn't this a good reason to actually require that the charset is handled correctly? For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT, workers). I really believe that piling up workarounds and inconsistencies like these makes the whole platform much harder to use than necessary. Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On 2011-11-18 13:44, Simon Pieters wrote: On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-18 13:03, Simon Pieters wrote: UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. What kind of server sets a charset on JS *and* cannot be configured not to? I don't know. I know we changed appcache to not do MIME type checking of the cache manifest because authors had trouble changing it. I know we sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and text/plain; charset=UTF-8 because it's the default in some servers. And, if this is the case, isn't this a good reason to actually require that the charset is handled correctly? For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT, workers). That's fine if you use a new type, or profile an existing one. But claiming that charset=... means something else before depending on the context it's used in is asking for trouble. I really believe that piling up workarounds and inconsistencies like these makes the whole platform much harder to use than necessary. Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. I'm ok with that. I'm not ok with treating something that has a charset of ISO-8859-1 silently as UTF-8, in particular when other parts of the platform disagree. Best regards, Julian
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke julian.resc...@gmx.de wrote: That's fine if you use a new type, or profile an existing one. But claiming that charset=... means something else before depending on the context it's used in is asking for trouble. What kind of trouble? Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. I'm ok with that. I'm not ok with treating something that has a charset of ISO-8859-1 silently as UTF-8, in particular when other parts of the platform disagree. Why not? We have context-dependent treatment of MIME types already (e.g. a text/html resource can be treated as a script). -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On 2011-11-18 14:04, Simon Pieters wrote: On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke julian.resc...@gmx.de wrote: That's fine if you use a new type, or profile an existing one. But claiming that charset=... means something else before depending on the context it's used in is asking for trouble. What kind of trouble? Trouble that other recipients disagree on that the encoding is. Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. I'm ok with that. I'm not ok with treating something that has a charset of ISO-8859-1 silently as UTF-8, in particular when other parts of the platform disagree. Why not? We have context-dependent treatment of MIME types already (e.g. a text/html resource can be treated as a script). These are workarounds because of legacy, I assume. Workers are a new feature. Best regards, Julian
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 14:10:36 +0100, Julian Reschke julian.resc...@gmx.de wrote: Why not? We have context-dependent treatment of MIME types already (e.g. a text/html resource can be treated as a script). These are workarounds because of legacy, I assume. Workers are a new feature. Workers ignore the MIME type. -- Simon Pieters Opera Software
CfC: publish a Candidate Recommendation of Web Storage; deadline Nov 25
The comment period for the October 25 LCWD of Web Storage [LC] ended November 15. No bugs were submitted since the LC was published. Two comments were submitted and they are tracked in: [1] http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011 I propose: a) the comments in [1] be addressed via updates to the [Database] wiki and/or new bugs reports for extensions to the spec; and b) we proceed to Candidate Recommendation (CR) using [LC] as the basis (the ED has not changed since October 4). As such, this is a Call for Consensus to publish a CR of Web Storage and I propose the CR's exit criteria is the same as our last proposed CR (Web Sockets): [[ To exit the Candidate Recommendation stage the following criteria must have been met: 1. There will be at least two interoperable implementations passing all approved test cases in the test suite for this specification. An implementation is to be available (i.e. for download), shipping (i.e. not private), and not experimental (i.e. intended for a wide audience). The working group will decide when the test suite is of sufficient quality to test interoperability and will produce an implementation report (hosted together with the test suite). 2. A minimum of three months of the CR stage will have elapsed (i.e. not until after @@ February/March 2012). This is to ensure that enough time is given for any remaining major errors to be caught. The CR period will be extended if implementations are slow to appear. ]] This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is November 25 and all comments should be sent to public-webapps at w3.org. -AB [LC] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [Database] http://www.w3.org/2008/webapps/wiki/Database
Re: Last Call Comments on Web Storage
Ashok - your comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-1 If you want to propose extensions or changes to Web Storage, please use [Bugzilla] and please feel free to contribute to the group's [Database] wiki. If you have any additional feedback, please reply by November 25, the day the CfC to publish a Candidate Recommendation for Web Storage ends [CfC]. -Art Barstow [Bugzilla] http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG [Database] http://www.w3.org/2008/webapps/wiki/Database [CfC] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html On 11/14/11 5:44 PM, ext Arthur Barstow wrote: Hi Ashok, I agree with Tab's comments and wanted to mention some of the related history ... The relationships between WebApps' various database related specs has been discussed before and [DB-wiki] was created to help clarify the relationships. The good news is there are now 2 specs rather than 4 but the wiki is a bit outdated so I recorded [Action-640] as a reminder to update it during Web Storage's CR period and inputs/updates from others is welcome. Additionally, because of some concerns about what I would call shortcomings of Web Storage when compared with IDB, last June we held a poll [RfC-Storage] to determine if there was consensus to continue work on that spec or to stop work on it (and to publish it as a WG Note). The consensus was to continue to move the spec to REC. -Art Barstow [DB-wiki] http://www.w3.org/2008/webapps/wiki/Database [RfC-Storage] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html [Action-640] http://www.w3.org/2008/webapps/track/actions/640 On 11/11/11 3:24 PM, ext Tab Atkins Jr. wrote: On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra ashok.malho...@oracle.com wrote: o One use of local storage might be to store personal preferences, such as travel preferences or personal information such as medical history. In such cases, you may want to allow several sites access to this information (I prefer aisle seats; I would like to stay at Marriott hotels.) Local storage is governed by the same-origin policy but in some cases it may be wise to carefully relax this and allow multiple sites to access the data. It seems that these are *not* the sort of thing you want to leave to ad-hoc data storage. Instead, this should be approached from a standardization perspective. o When updating local storage, transactional semantics or, at least, a transactional option would be desirable. IndexedDB is intended to be the better version of localStorage, and utilizes transactional semantics. o It would be very useful to be able to map from other forms of data storage, such as RDF or Relational data to RDF. Mapping from RDF would be simple. Mapping from Relational is more challenging. What's the use-case for taking in RDF and storing it in localStorage? One can always just store RDF directly as a localStorage *value*. o If local storage is used to store personal preferences or personal information it would be very useful to be able to move it from one device to another, say my laptop to my phone. This is left to either the app or the browser to achieve. o Question: The values in the key-value pairs are typed as strings but I presume they can be URIs and be interpreted as URIs. Or they can be large files. Perhaps this could be clarified. They are always strings, but of course they can represent any type of data that can be stringified and revived. The application can choose to interpret them as urls or files if it wishes. However, storing large files is better done through the FileSystem API or through IndexedDB. ~TJ
Re: CfC: publish a Candidate Recommendation of Web Storage; deadline Nov 25
On Friday, November 18, 2011 at 3:58 PM, Arthur Barstow wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is November 25 and all comments should be sent to public-webapps at w3.org (http://w3.org). I support this.
Re: TAG Comment on
Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 Thank you. Noah On 11/18/2011 10:01 AM, Arthur Barstow wrote: Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 If anyone wants to propose extensions or changes to Web Storage, please use [Bugzilla] and please feel free to contribute to the group's [Database] wiki e.g. to clarify the relationship between Web Storage and HTML5's AppCache. If you have any additional feedback, please reply by November 25, the day the CfC to publish a Candidate Recommendation of Web Storage ends [CfC]. -Art Barstow [Bugzilla] http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG [Database] http://www.w3.org/2008/webapps/wiki/Database [CfC] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html On 11/15/11 5:05 PM, ext Noah Mendelsohn wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: Synchronous postMessage for Workers?
On Thu, Nov 17, 2011 at 10:33 PM, David Levin le...@chromium.org wrote:
Ah so the proposal is really only adding a new method only
on DedicatedWorkerGlobalScope which send a synchronous message and
something corresponding on Worker which can respond to this.
There's no need for a new sending method; only a receiving method. To
reuse the original example:
postMessage({action: prompt_user, prompt: How about a nice game of
chess?});
var msg = waitForMessage();
if(msg msg.data) { chess_game.begin(); }
The other side is as usual:
worker.onmessage = function(e) { worker.postMessage(true); }
without caring which API the worker is using to receive the response.
Note that the nonblocking case should definitely work on all ports.
There's no risk of deadlocks when not blocking.
--
Glenn Maynard
Re: Synchronous postMessage for Workers?
On Fri, Nov 18, 2011 at 8:16 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Nov 17, 2011 at 10:33 PM, David Levin le...@chromium.org wrote:
Ah so the proposal is really only adding a new method only
on DedicatedWorkerGlobalScope which send a synchronous message and
something corresponding on Worker which can respond to this.
There's no need for a new sending method; only a receiving method. To
reuse the original example:
postMessage({action: prompt_user, prompt: How about a nice game of
chess?});
var msg = waitForMessage();
if(msg msg.data) { chess_game.begin(); }
The other side is as usual:
worker.onmessage = function(e) { worker.postMessage(true); }
without caring which API the worker is using to receive the response.
So the primary use case is code in the worker which has no other (async)
messages coming in?
dave
[Web Intents] Task Force Mailing List set up
The Web Intents Task Force is starting to take shape! If you'd like to be a part of shaping this API, please involve yourself by joining the new mailing list. A W3C mailing list has been set up: http://lists.w3.org/Archives/Public/public-web-intents/ To subscribe to this mailing list, send an email to public-web-intents-requ...@w3.org with the subject 'subscribe'. We've created a group for the TF: http://www.w3.org/2000/09/dbwg/details?group=50861public=1, though it's just a placeholder for now since the logistics of the group have not been worked out completely yet. I'll let you know once I know more. I'm in the process of uploading the draft of the API to w3.org; I'll send a message to public-web-intents once that's complete. Thanks, James
Re: Synchronous postMessage for Workers?
On Fri, Nov 18, 2011 at 11:50 AM, David Levin le...@chromium.org wrote: So the primary use case is code in the worker which has no other (async) messages coming in? No--you can always create another message channel for other types of messages, if you need to. (Of course, you shouldn't receive messages on other ports *while* blocking; that is, the event loop isn't spun while waiting. That's just the same as any other synchronous worker API.) -- Glenn Maynard
Re: Synchronous postMessage for Workers?
On Fri, Nov 18, 2011 at 12:18 PM, David Levin le...@chromium.org wrote:
The primary use case is one in which messages sent to
DedicatedWorkerGlobalScope are reserved for synchronous messaging.
Mostly, yes, or otherwise dealing with unrelated messages coming in while
you're waiting for a response.
It's possible to safely use async and sync message receipt on the same
channel. For example,
onmessage = function(e)
{
if(e.data.message == pause)
{
msg = waitForMessage();
// assert(msg.message == continue);
}
}
and in the main thread,
worker.postMessage({message = pause});
alert(The worker is currently paused and waiting to be continued);
worker.postMessage({message = continue});
Once you send pause, events and timers in the worker will be deferred
until you resume it. Since messages are delivered in order, this is
guaranteed to work.
(By the way, the above isn't why I prefer this API; I prefer it because it
avoids adding more messaging mechanisms and it creates a simpler API. The
above is just an interesting way it might be used.)
--
Glenn Maynard
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com wrote: ** On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.comwrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. -- Paul Kinlan Developer Advocate @ Google for Chrome and HTML5 G+: http://plus.ly/paul.kinlan t: +447730517944 tw: @Paul_Kinlan LinkedIn: http://uk.linkedin.com/in/paulkinlan Blog: http://paul.kinlan.me Skype: paul.kinlan
Re: Synchronous postMessage for Workers?
On Nov 18, 2011, at 12:56 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Nov 18, 2011 at 12:18 PM, David Levin le...@chromium.org wrote:
The primary use case is one in which messages sent to
DedicatedWorkerGlobalScope are reserved for synchronous messaging.
Mostly, yes, or otherwise dealing with unrelated messages coming in while
you're waiting for a response.
It's possible to safely use async and sync message receipt on the same
channel. For example,
onmessage = function(e)
{
if(e.data.message == pause)
{
msg = waitForMessage();
// assert(msg.message == continue);
The name waitForMessage() definitely has a promise/futures connotation...
}
}
and in the main thread,
worker.postMessage({message = pause});
alert(The worker is currently paused and waiting to be continued);
worker.postMessage({message = continue});
My initial concerns aside and with no trolling intentions... The above literal
expressions are all syntax errors, = should be :
Once you send pause, events and timers in the worker will be deferred until
you resume it. Since messages are delivered in order, this is guaranteed to
work.
(By the way, the above isn't why I prefer this API; I prefer it because it
avoids adding more messaging mechanisms and it creates a simpler API. The
above is just an interesting way it might be used.)
--
Glenn Maynard
Re: Synchronous postMessage for Workers?
On Fri, Nov 18, 2011 at 1:33 PM, Rick Waldron waldron.r...@gmail.comwrote: My initial concerns aside and with no trolling intentions... The above literal expressions are all syntax errors, = should be : A typo I make regularly; it's a side-effect of using having too many languages rattling around in my head at once. (Lua uses =.) -- Glenn Maynard
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/18/11 10:29 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. Yes, I understand the reference. It's important that services are register themselves to appropriate mime types and intents. The intent field is a simple DOMString, and it's reasonably wide-open for use. Should we treat the mime type field in similar manner? Web messaging is so-easy to use, I'd expect a flood of micro-protocols. What's our plumbing to effectively work with the postMessage transfer semantic? It seems like transfer might be a special case intent. Everything else does a data copy. Transferring an array buffer means the current thread can no longer access that buffer. This is, approximately, what I'm thinking about: var intent = new Intent(http://webintents.org/transfer;, application/octet-stream+myprotocol, [messagePort, arrayBuffer]); The transfer intent signals that postMessage transfer semantics are going to be used. -Charles
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
I'd like to request that people stop sending posts about web intents to public-webapps@w3.org and public-device-a...@w3.org The new list exists and should be used: http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/ On 11/18/11, Charles Pritchard ch...@jumis.com wrote: On 11/18/11 10:29 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. Yes, I understand the reference. It's important that services are register themselves to appropriate mime types and intents. The intent field is a simple DOMString, and it's reasonably wide-open for use. Should we treat the mime type field in similar manner? Web messaging is so-easy to use, I'd expect a flood of micro-protocols. What's our plumbing to effectively work with the postMessage transfer semantic? It seems like transfer might be a special case intent. Everything else does a data copy. Transferring an array buffer means the current thread can no longer access that buffer. This is, approximately, what I'm thinking about: var intent = new Intent(http://webintents.org/transfer;, application/octet-stream+myprotocol, [messagePort, arrayBuffer]); The transfer intent signals that postMessage transfer semantics are going to be used. -Charles -- Sent from my mobile device
Re: [IndexedDB] transaction order
On Mon, Oct 24, 2011 at 10:22 AM, Israel Hilerio isra...@microsoft.com wrote:
On Friday, October 14, 2011 6:42 PM, Jonas Sicking wrote:
On Fri, Oct 14, 2011 at 1:51 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
Hi All,
There is one edge case regarding transaction scheduling that we'd
like to get clarified.
As the spec is written, it's clear what the following code should do:
trans1 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans1.objectStore(foo).put(value 1, mykey);
trans2 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans2.objectStore(foo).put(value 2, mykey);
In this example it's clear that the implementation should first run
trans1 which will put the value value 1 in object store foo at
key mykey. The implementation should then run trans2 which will
write overwrite the same value with value 2. The end result is
that value 2 is the value that lives in the object store.
Note that in this case it's not at all ambiguous which transaction runs
first.
Since the two transactions have overlapping scope, trans2 won't
even start until trans1 is committed. Even if we made the code something
like:
trans1 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans1.objectStore(foo).put(value 1, mykey);
trans2 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans2.objectStore(foo).put(value 2, mykey);
trans1.objectStore(foo).put(value 3, mykey);
we'd get the same result. Both put requests placed against trans1
will run first while trans2 is waiting for trans1 to commit before
it begins running since they have overlapping scopes.
However, consider the following example:
trans1 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans2 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans2.objectStore(foo).put(value 2, mykey);
trans1.objectStore(foo).put(value 1, mykey);
In this case, while trans1 is created first, no requests are placed
against it, and so no database operations are started. The first
database operation that is requested is one placed against trans2.
In the firefox implementation, this makes trans2 run before trans1. I.e.
we schedule transactions when the first request is placed against
them, and not when the IDBDatabase.transaction() function returns.
The advantage of firefox approach is obvious in code like this:
someElement.onclick = function() {
trans1 = db.transaction([foo], IDBTransaction.READ_WRITE);
...
trans2 = db.transaction([foo], IDBTransaction.READ_WRITE);
trans2.objectStore.put(some value, mykey);
callExpensiveFunction();
}
In this example no requests are placed against trans1. However
since
trans1 is supposed to run before trans2 does, we can't send off any
work to the database at the time when the .put call happens since
we don't yet know if there will be requests placed against trans1.
Only once we return to the event loop at the end of the onclick
handler will
trans1 be committed
and the requests in trans2 can be sent to the database.
However, the downside with firefox approach is that it's harder for
applications to control which order transactions are run. Consider
for example a program is parsing a big hunk of binary data. Before
parsing, the program starts two transactions, one READ_WRITE and
one READ_ONLY. As the binary data is interpreted, the program
issues write requests against the READ_WRITE transactions and read
requests against the READ_ONLY transaction. The idea being that the
read requests will always run after the write requests to read from
database after all the parsed data has been written. In this setup
the firefox approach isn't as good since it's less predictable
which transaction will run first as it might depend on the binary
data being parsed. Of course, you could force the writing
transaction to run first by placing a request
against it after it has been created.
I am however not able to think of any concrete examples of the
above binary data structure that would require this setup.
So the question is, which solution do you think we should go with.
One thing to remember is that there is a very small difference
between the two approaches here. It only makes a difference in edge
cases. The edge case being that a transaction is created, but no
requests are placed against it until another transaction, with
overlapping scope, is
created.
Firefox approach has strictly better performance in this edge case.
However it could also have somewhat surprising results.
I personally don't feel strongly either way. I also think it's rare
to make a difference one way or another as it'll be rare for people
to hit this
edge case.
Re: Synchronous postMessage for Workers?
* Joshua Bell wrote: Jonas and I were having an offline discussing regarding the synchronous Indexed Database API and noting how clean and straightforward it will allow Worker scripts to be. One general Worker issue we noted - independent of IDB - was that there are cases where Worker scripts may need to fetch data from the Window. This can be done today using bidirectional postMessage, but of course this requires the Worker to then be coded in now common asynchronous JavaScript fashion, with either a tangled mess of callbacks or some sort of Promises/Futures library, which removes some of the benefits of introducing sync APIs to Workers in the first place. I note that you can overcome manually coded continuation passing style by exposing the continuations. In JavaScript 1.7 Generators do that in some limited fashion: a generator can yield control to the calling code, which can then resume the generator at its discretion, allowing you to implement Wait functions that wait for whatever you want them waiting for, for however long you might want them to wait for it. Some years ago I made http://lists.w3.org/Archives/Public/www-archive/2008Jul/0009.html as a quick example of using generators in this manner. The generator there essentially schedules resource loads and yields con- trol until the resource finishes loading in which case the event handler would resume the generator. A more realistic example would schedule all the resources needed to proceed and watch out for load failures and so on, but it demonstrates that cooperative multitasking is quite feasible. Obviously, even if ES.next provides better support for this, it is a good bit more complicated to use directly, and easier to get wrong, than a dedicated solution with limited scope as you propose for this special case, but adding blocking APIs here and there to address a few use cases also doesn't strike me as the best approach. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Opening discussion on StreamWorker
On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com wrote:
On 11/17/2011 4:52 PM, Charles Pritchard wrote:
Currently, Web Workers provides a heavy scope for multithreaded Web
Apps to handle heavy data processing.
I'd like to draw on those specs and create a new lightweight scope useful
for various data processing tasks typically associated with stream
processing and GPUs.
CSS/FX is looking at custom filter tags using WebGL. I think we can
implement these in Workers as well. The most important constraints are that
the data is opaque: no shared storage allowed.
There are many examples of using web workers to apply effects to 32bit
pixel data. Those could be easily applied to CSS pixel filters just as
WebGL shaders are.
River Trail and W16 are showing us ways in which tight for loops can take
advantage of multiple cores.
Let's look at these use cases and consider a new lightweight worker
scope. Nothing but the bare bones, designed and expected to be used for a
very specific type of task.
Existing CanvasPixelArray processing scripts are a great place to start.
I suspect we'll be able to handle other cases, such as stream ciphers.
I'm still trying to bikeshed a name on this... StreamWorker,
OpaqueWorker, SimpleWorker, DataWorker etc.
Please join me in the discussion. I think we can make rapid progress here
now that Transferable has matured and we have two moderately-parallel JS
implementations.
To be more clear: here is some in-the-wild code that is similar to what
I'd expect to produce and consume with StreamWorker:
http://code.google.com/p/**chromabrush/source/browse/**
frontend/js/filter.blur.jshttp://code.google.com/p/chromabrush/source/browse/frontend/js/filter.blur.js
Pseudo-code:
onmessage(data) { for(... data) { data[i] *= fancyness; };
postMessage(data); };
In doing this, could attach to CSS such as: img { filter:
custom(url('basicpixelworker.**js')); }.
The worker may only use postMessage once, and it must send back an array
of the same size.
There are no other options, no ways to pass a message to other contexts,
no File or IDB or other APIs.
The concept here is to be very restrictive. That way, no data is leaked,
and it behaves more like a WebGL shader (think GPGPU) than our existing web
worker context.
If it's rigid, we can get very good performance, high parallelism, and
modularity. We can also get quick implementation from vendors.
And they can decide when they want to optimize.
Can you clarify what optimizations are enabled by these workers? It's not
clear to me that removing APIs makes starting up a worker any more
efficient, and I don't think significant efficiencies are enabled by
restricting workers to only sending/receiving a single message per
execution.
As a completely different use case, such a simple worker could provide
stream encryption, or perhaps some other kind of basic but heavy number
crunching. Since it's just a simple in-out routine, it can be highly
optimized and easily added into API pipelines.
These workers would still be backward compatible. They could still be used
as normal web workers. But in their more basic state, they can be more
lightweight, there are no side effects
and so they are more appropriate for massive parallelism.
-Charles
Re: Opening discussion on StreamWorker
On 11/18/11 5:35 PM, Andrew Wilson wrote:
On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/17/2011 4:52 PM, Charles Pritchard wrote:
Currently, Web Workers provides a heavy scope for
multithreaded Web Apps to handle heavy data processing.
I'd like to draw on those specs and create a new lightweight
scope useful for various data processing tasks typically
associated with stream processing and GPUs.
Pseudo-code:
onmessage(data) { for(... data) { data[i] *= fancyness; };
postMessage(data); };
In doing this, could attach to CSS such as: img { filter:
custom(url('basicpixelworker.js')); }.
The worker may only use postMessage once, and it must send back an
array of the same size.
There are no other options, no ways to pass a message to other
contexts, no File or IDB or other APIs.
The concept here is to be very restrictive. That way, no data is
leaked, and it behaves more like a WebGL shader (think GPGPU) than
our existing web worker context.
If it's rigid, we can get very good performance, high parallelism,
and modularity. We can also get quick implementation from vendors.
And they can decide when they want to optimize.
Can you clarify what optimizations are enabled by these workers? It's
not clear to me that removing APIs makes starting up a worker any more
efficient, and I don't think significant efficiencies are enabled by
restricting workers to only sending/receiving a single message per
execution.
For the image filtering use case -- a restricted worker process would be
as secure as WebGL is for pixel shaders.
That's the main reason for removing the APIs.
I don't think significant efficiencies are enabled by single get/post
messages either. But it may make implementation of optimizations easier.
This is proposal intended for a new worker type, a subset of existing
worker behavior. It's not meant to alter existing workers.
I can't speak to performance optimizations with expertise. I'd need to
hunt down some experts in the field to give a useful information.
A sufficiently simple JS program could be optimized to run on a GPU
array, but that's not a short-term goal.
For working with simple parallelism:
Intel went one route, see: ParallelArray Data Structure, Elemental
Functions:
https://github.com/RiverTrail/RiverTrail/wiki/API-Design
W16 went another route using STM noting most effective optimizations
were disabled to simplify implementation:
https://github.com/sheremetyev/w16/blob/master/README.md
I'm focused on pixel shaders as a use case. RiverTrail makes
optimization opportunities fairly explicit by introducing new data types,
W16 makes minimal changes on V8 to try to enhance parallelism.
-Charles
