[Bug 10794] [IndexedDB] Clarify createObjectStore/removeObjectStore's tie to the database setVersion was called on
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10794 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Eliot Graff eliot...@microsoft.com 2011-06-03 06:05:27 UTC --- Added the following sentences: ]] The createObjectStore method is tied to the instance of the database that setVersion was called on and can make changes to that database instance only. The deleteObjectStore method is tied to the instance of the database that setVersion was called on and can make changes to that database instance only. [[ to the following methods: IDBDatabase.createObjectStore IDBDatabase.deleteObjectStore IDBDatabaseSync.createObjectStore IDBDatabaseSync.deleteObjectStore -- 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: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn into a problem, it would seem like a problem no matter what
solution is used, no?
Not if all objects are transferred.
Define all objects. Consider something like:
a = { x: myArrayBuffer1, y: myArrayBuffer2 };
worker.postMessage(a, { transfer: true });
In this case the 'a' object is obviously not transferred. Or are you
proposing that it'd be transferred too somehow?
Well the algorithm could empty 'a'. As far as what happens underneath the
covers that is up to the implementation. (I suspect most javascript engines
today wouldn't allow for actually transferring the memory cross thread.)
Here's a simple use case, suppose I create an array of arrays (a 2d
array)
which contains ArrayBuffers.Now I want to transfer this as fast as
possible
using postMessage.
What does my code look like for each of these apis?
Your proposal:
w.postMessage(my2darray, {transfer: true});
vs.
w.postMessage(my2darray, Array.concat.apply(Array, my2darray));
I thought this would be:
w.postMessage(my2darray, {transfer: Array.concat.apply(Array,
my2darray)});
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which may or may not contain ArrayBuffers.
Fair enough. Way more complicated for the transfer: true case. :)
The thing that seemed odd to me about this extra array is that it seemed to
make the code more complicated and harder to understand. However, I
understand that folks want to support involved scenarios.
*Let's go with the transfer list.* (I suspect that something like transfer:
true or transfer: all would still be possible in the future if it proved
desirable since bools/strings won't be valid there.)
dave
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 2:44 AM, Dmitry Lomov dslo...@chromium.org wrote:
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which may or may not contain ArrayBuffers.
I think this can be reversed: what if you got some data from some other
piece of code that you do not really control and you want to transfer (i.e.
transfer all the ArrayBuffers that are inside that data)?
As in, the library gives you two methods, compute() that returns data and
present(data) that presents it, and you want to pass data from worker to
main thread without really caring what is inside that data.
One possibility would be, in addition to instances of object, to also
allow providing the object constructor, indicating that all objects of
that type should be transferred if supported. {transfer:
[ArrayBuffer, ImageData]}
--
Glenn Maynard
FW: CORS and HTTP headers spoofing
How would you set the Origin header? I have figured out at least one unexpected and surprisingly easy way to do it in Firefox. There is a firefox addon available , which lets set Origin header to any value. Addon is available from the following link: https://addons.mozilla.org/en-US/firefox/addon/modify-headers/ I have installed it and tried it with one simple web application. Well, what can I say... It works, and with this addon I can send a cross origin XHR with any value of Origin header. So your concern is that the user would install an addon and use that to attack a target site? What type of attack are you concerned that the user would be able to perform? I.e. what type of data are you worried that the user could steal? Or what type of harm are you worried that the user would be able to cause on the website? In this particular case, the user might be not aware that there is any this kind of addon running in browser and changing the value of Origin header. And then it is becoming even easier for CSRF, as XHR can be sent automatically and user even doesn't need to click to any malicious link. But answering your question, the type of stolen data and type of harm depends on the logic implemented on the server. CORS was mostly written with the intent of protecting the users data which is stored in various web servers. Obviously the user attacking the webserver to steal his or her own data isn't much of a concern. This is why I'm asking the above question. I am trying to figure out, how the Origin header of request should be used on the side of server. Adam Barth wrote the following in http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1255.html:My understanding is that the CORS use of the Origin header is mostly to protect the confientiality of resources on the server. For example, if (1) the server wishes to reveal a particular piece of information to some origins by not to others.Before my understanding was compliant with Adam's, I was thinking about resources on the server in general, not only users' data. Best regardsMargarita Podskrobko
Re: Request for feedback: DOMCrypt API proposal
I wonder whether the problem is actually just one of generating
sufficiently cryptographically secure PRNGs or whether there are real
benefits to creating a full-blown UA-based Crypto API and the can of
worms that might open.
There was a proposal on the WHATWG back in February for producing a
cryptographic pseudo-random number generation API (ala the NS4
window.crypto.random API IIRC) within browsers [1].
A 2009 Stanford white paper entitled 'Symmetric Cryptography in
Javascript' [2] detailed a number of optimizations to make symmetric
cryptography performant in pure-Javascript (i.e. maximizing
precomputation, loop unrolling, bitslicing). There is an implementation
available at [3]. The paper concluded by saying that one of their
biggest problems was finding a way to generate enough cryptographic
randomness in the browser for key generation - other than that their
solution is quite performant.
So would window.crypto.random allow performant symmetric and asymmetric
cryptography to be written in pure JS? It would be good to see some
benchmarks between JS and Native around SHA256 and SHA512 key generation
(for example) to really understand the performance benefits that this
API could bring.
Other than that, it's still a very rough proposal but it could be
interesting pending some performance benchmark data (or details of
additional benefits that this proposal brings) :)
- Rich
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030241.html
[2] http://crypto.stanford.edu/sjcl/acsac.pdf
[3] http://crypto.stanford.edu/sjcl/
David Dahl wrote:
Hello public-webapps members,
(I wanted to post this proposed draft spec for the DOMCrypt API (
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list
- if there is a more fitting mailing list, please let me know)
I recently posted this draft spec for a crypto API for browsers to the whatwg
(see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html)
and wanted to get feedback from W3C as well.
Privacy and user control on the web is of utter importance. Tracking,
unauthorized user data aggregation and personal information breaches are
becoming so commonplace you see a new headline almost daily. (It seems).
We need crypto APIs in browsers to allow developers to create more secure
communications tools and web applications that don’t have to implicitly trust
the server, among other use cases.
The DOMCrypt API is a good start, and more feedback and discussion will really
help round out how all of this should work – as well as how it can work in any
browser that will support such an API.
This API will provide each web browser window with a ‘cipher’ property[1] that
facilitates:
asymmetric encryption key pair generation
public key encryption
public key decryption
symmetric encryption
signature generation
signature verification
hashing
easy public key discovery via meta tags or an ‘addressbookentry’ tag
[1] There is a bit of discussion around adding this API to window.navigator or
consolidation within window.crypto
I have created a Firefox extension that implements most of the above, and am
working on an experimental patch that integrates this API into Firefox.
The project originated in an extension I wrote, the home page is here:
http://domcrypt.org
The source code for the extension is here: https://github.com/daviddahl/domcrypt
The Mozilla bugs are here:
https://bugzilla.mozilla.org/show_bug.cgi?id=649154
https://bugzilla.mozilla.org/show_bug.cgi?id=657432
Firefox feature wiki page:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
You can test the API by installing the extension hosted at domcrypt.org, and
going to http://domcrypt.org
A recent blog post updating all of this is posted here:
http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
The API:
window.cipher = {
// Public Key API
pk: {
set algorithm(algorithm){ },
get algorithm(){ },
// Generate a keypair and then execute the callback function
generateKeypair: function ( function callback( aPublicKey ) { } ) { },
// encrypt a plainText
encrypt: function ( plainText, function callback (cipherMessageObject) ) {
} ) { },
// decrypt a cipherMessage
decrypt: function ( cipherMessageObject, function callback ( plainText ) { }
) { },
// sign a message
sign: function ( plainText, function callback ( signature ) { } ) { },
// verify a signature
verify: function ( signature, plainText, function callback ( boolean ) { } )
{ },
// get the JSON cipherAddressbook
get addressbook() {},
// make changes to the addressbook
saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
}) { }
},
// Symmetric Crypto API
sym: {
get algorithm(),
set algorithm(algorithm),
// create a new symmetric key
generateKey: function (function callback (
[WARP] Not clear what blocking is
The spec says: At runtime, when a network request is made from within the widget execution scope, the user agent matches it against the rules defined above, accepting it if it matches and blocking it if it doesn't. However, *blocking* is not defined. This has lead to inconstant behavior across user agents. Some engines throw a SECURITY_ERR and shut down the scripting environment, while others behave as if the resource could not be loaded. Blocking needs to be properly defined if we are going to get any interop... particularly what it means to block http/https resources.
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
[port]});
There are two properties of this approach that I like:
1. It means that objects which you'd like to transfer ownership are
not second class citizens and can live as part of the normal object
graph that is posted, together with metadata that goes with it (or
even as metadata for other things).
2. The receiving side doesn't need to worry about the difference, all
it gets is the graph of objects that was sent to it.
Yep, I totally agree with this. All of the current solutions being
discussed
satisfy both of these in fact.
It also raises questions when I see it. When I list an object there
does
it
imply that all children are also transfered or do I have to list each
of
them explicitly as well?)
None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn into a problem, it would seem like a problem no matter what
solution is used, no?
Not if all objects are transferred.
Define all objects. Consider something like:
a = { x: myArrayBuffer1, y: myArrayBuffer2 };
worker.postMessage(a, { transfer: true });
In this case the 'a' object is obviously not transferred. Or are you
proposing that it'd be transferred too somehow?
Then I wonder what is the use case for this complexity.
Why not something simpler like this?
port.postMessage({frameBuffer: frame}, {transfer: true, ports:
[port]});
where you can just say indicate that you want the message transfered.
This means that you have to choose between transferring all arrays and
transferring none of them.
Yep, why add the complication of picking individual items to transfer
over? (I'm wary of second system syndrome, which I've seen happen many
times in various designs.)
It also makes it much less explicit which
objects ends up being mutated.
It is all of them.
Sure, but what all includes might not be obvious to the web
developer in all cases. For example if you're receiving an object from
some subsystem that you intend to do processing on. You later decide
to do the processing in a thread and throw that object into an array
alongside with some other data. Some of the other data you are
throwing in includes some big arrays that you want to avoid copying
and so you choose to use the transfer rather than copy mode.
Now you all of a sudden start modifying the data that you got from the
other subsystem. This is data that you might normally not be even
looking at. The fact that it happened to contain some ArrayBuffers was
just a side effect of that that was the data structures that the other
subsystem uses and was easy for it to return to you.
Here's a simple use case, suppose I create an array of arrays (a 2d
array)
which contains ArrayBuffers.Now I want to transfer this as fast as
possible
using postMessage.
What does my code look like for each of these apis?
Your proposal:
w.postMessage(my2darray, {transfer: true});
vs.
w.postMessage(my2darray, Array.concat.apply(Array, my2darray));
Hmm, if my2darray is large, the latter is pretty wasteful.
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which may or may not contain ArrayBuffers.
I think this can be reversed: what if you got some data from some other
piece of code that you do not really control and you want to transfer (i.e.
transfer all the ArrayBuffers that are inside that data)?
As in, the library gives you two methods, compute() that returns data and
present(data) that presents it, and you want to pass data from worker to
main thread without really caring what is inside that data.
/ Jonas
Thanks!
Dmitry
Re: [WARP] error in spec
Hi Marcos - given this spec is in the Candidate Recommendation state, before a CfC to publish a new LCWD is started, I think it would be helpful if you provided a list of the changes you propose and a short summary for each change. WDYT? I don't have a strong opinion on where the list of changes is documented but I think you previously included change lists in the spec itself and that would be fine here too. -AB On Jun/2/2011 11:24 AM, ext Marcos Caceres wrote: On 6/2/11 5:13 PM, Marcos Caceres wrote: On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceresmarcosscace...@gmail.com wrote: Quote from WARP: Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. subdomains has a default value of false so why is ignoring the completeaccess element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. Proposed fix: [[ 5. If the subdomins attribute is absent, then let sub domains be the value false. Otherwise, or let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. 6. If the value of sub domains is not a valid boolean value, then let sub domains be the value false. ]] I've put that into the editor's draft. I call to republish the spec with the correction ASAP. Kind regards, Marcos
Re: FW: CORS and HTTP headers spoofing
On 6/3/11 6:02 AM, Margarita Podskrobko wrote: In this particular case, the user might be not aware that there is any this kind of addon running in browser and changing the value of Origin header. If the user doesn't know what addons are running in the browser, then the user is screwed. Addons can break the security model in pretty arbitrary ways, on purpose. And then it is becoming even easier for CSRF, as XHR can be sent automatically and user even doesn't need to click to any malicious link. An addon can do anything the browser itself can do. So if the user can visit a site, an addon can scrape the site. An addon is just part of the browser, for security purposes. Not trusting it is equivalent to not trusting the browser itself. Possibly rational, but useless in practice unless you're just planning not to use that browser at all. CORS was mostly written with the intent of protecting the users data which is stored in various web servers. Obviously the user attacking the webserver to steal his or her own data isn't much of a concern. This is why I'm asking the above question. I am trying to figure out, how the Origin header of request should be used on the side of server. Adam Barth wrote the following in http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1255.html: My understanding is that the CORS use of the Origin header is mostly to protect the confientiality of resources on the server. For example, if (1) the server wishes to reveal a particular piece of information to some origins by not to others. This implies the server trusting that the browser won't purposefully try to screw that up. There is no way to protect against the browser (or heck, the _user_) being malicious. Consider that the user could just get the data from the server and then e-mail it to some other website. The idea here is that the _user_'s data is on the server and the user wishes it to be secure. The server allows some other sites but not others to access the data because the sites it allows are trusted and need to work with the data. If the user wishes to circumvent this setup, that's fine: it's the user's data to start with. Servers that want to protect their _own_ data just need to not put it on the web at all, and they're done! -Boris
Re: Testing Requirements
On Thu, 2011-06-02 at 20:15 +0200, Marcos Caceres wrote: On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret p...@w3.org wrote: On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote: Hi Philippe, Just wondering if we have different port support yet on test-w3c.org? Would be nice to at least have 81, 82 or something (any none-standard ports would be fine for me). I need ports to finish off the Widget Access Request Test Suite. Nope, I don't believe we have that but that should relatively easy to add. How many extra do you need? Just a few (2 or 3). I think Anne will also appreciate this for the XHR test suite. You now have: http://www.w3c-test.org:81/ http://www.w3c-test.org:82/ http://www.w3c-test.org:83/ Philippe
[widgets] WARP summary of issues, was Re: [WARP] error in spec
On 6/3/11 1:39 PM, Arthur Barstow wrote: Hi Marcos - given this spec is in the Candidate Recommendation state, before a CfC to publish a new LCWD is started, I think it would be helpful if you provided a list of the changes you propose and a short summary for each change. WDYT? I don't have a strong opinion on where the list of changes is documented but I think you previously included change lists in the spec itself and that would be fine here too. ISSUE 1: Blocking is undefined. The spec says: At runtime, when a network request is made from within the widget execution scope, the user agent matches it against the rules defined above, accepting it if it matches and blocking it if it doesn't. THE PROBLEM: blocking is undefined (which has lead to interop issues). SOLUTION: The user agent MUST behave as if the resource was unreachable (i.e., as if a invalid http address had been given or a 4XX or 5XX had been returned). This should cause, for example, HTML's elements to fire error when they try to load. For XHR, I think it's fine for a user agent to throw the SECURITY_ERR. This should be a RECOMMENDATION for user agents that implement XHR. === ISSUE 2: WARP is too strict PROBLEM: WARP rejects URLs too aggressively. It should be more liberal in what it excepts. SOLUTION: Parse URLs and just extract the useful bits (scheme, host, port). Discard the rest (path, iuserinfo, etc). ISSUE 3: subdomains attribute is not parsed consistently PROBLEM: subdomains attribute is not parsed the same way as other Boolean attributes defined in PC. It should not reject the whole access request when the value is wrong. SOLUTION: If subdomains is in error, then ignore it (and default to false). Don't reject the whole tag because of it.
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 11:44 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org
wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org
wrote:
port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
[port]});
There are two properties of this approach that I like:
1. It means that objects which you'd like to transfer ownership are
not second class citizens and can live as part of the normal object
graph that is posted, together with metadata that goes with it (or
even as metadata for other things).
2. The receiving side doesn't need to worry about the difference, all
it gets is the graph of objects that was sent to it.
Yep, I totally agree with this. All of the current solutions being
discussed
satisfy both of these in fact.
It also raises questions when I see it. When I list an object there
does
it
imply that all children are also transfered or do I have to list each
of
them explicitly as well?)
None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn into a problem, it would seem like a problem no matter what
solution is used, no?
Not if all objects are transferred.
Define all objects. Consider something like:
a = { x: myArrayBuffer1, y: myArrayBuffer2 };
worker.postMessage(a, { transfer: true });
In this case the 'a' object is obviously not transferred. Or are you
proposing that it'd be transferred too somehow?
Then I wonder what is the use case for this complexity.
Why not something simpler like this?
port.postMessage({frameBuffer: frame}, {transfer: true, ports:
[port]});
where you can just say indicate that you want the message transfered.
This means that you have to choose between transferring all arrays and
transferring none of them.
Yep, why add the complication of picking individual items to transfer
over? (I'm wary of second system syndrome, which I've seen happen many
times in various designs.)
It also makes it much less explicit which
objects ends up being mutated.
It is all of them.
Sure, but what all includes might not be obvious to the web
developer in all cases. For example if you're receiving an object from
some subsystem that you intend to do processing on. You later decide
to do the processing in a thread and throw that object into an array
alongside with some other data. Some of the other data you are
throwing in includes some big arrays that you want to avoid copying
and so you choose to use the transfer rather than copy mode.
Now you all of a sudden start modifying the data that you got from the
other subsystem. This is data that you might normally not be even
looking at. The fact that it happened to contain some ArrayBuffers was
just a side effect of that that was the data structures that the other
subsystem uses and was easy for it to return to you.
Here's a simple use case, suppose I create an array of arrays (a 2d
array)
which contains ArrayBuffers.Now I want to transfer this as fast as
possible
using postMessage.
What does my code look like for each of these apis?
Your proposal:
w.postMessage(my2darray, {transfer: true});
vs.
w.postMessage(my2darray, Array.concat.apply(Array, my2darray));
Hmm, if my2darray is large, the latter is pretty wasteful.
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which may or may not contain ArrayBuffers.
I think this can be reversed: what if you got some data from some other
piece of code that you do not really control and you want to transfer (i.e.
transfer all the ArrayBuffers that are inside that data)?
As in, the library gives you two methods, compute() that returns data and
present(data) that presents it, and you want to pass data from worker to
main thread without really caring what is inside that data.
/ Jonas
So, to clarify, we have two competing requirements here:
1) exercise fine-grained control over which parts of the message are
transfrerred
2) be able to transfer objects opaquely, for modularity or performance
reasons.
Here are two proposals that satisfy both:
a) *Recursive transfer lists*. Allow arbitrary objects, not only
ArrayBuffers, to appear in transfer lists. ArrayBuffers that are under
objects in transfer lists are transferred, others are cloned. (This leaves
the question, what happens to objects that are shared between objects in
transfer lists and others. It looks like the sane answer to
Re: Request for feedback: DOMCrypt API proposal
- Original Message - From: Adam Barth w...@adambarth.com To: David Dahl dd...@mozilla.com Cc: public-webapps@w3.org Sent: Thursday, June 2, 2011 8:57:11 PM Subject: Re: Request for feedback: DOMCrypt API proposal Really, the API should be algorithm agnostic. We can discuss separately which algorithms to provide. So, perhaps adding a setter and getter to the hash API and change it to hash.createHash() ? Of course we can also set a safe default. In the pk API, there doesn't seem to be any way to install a public/private keypair from another location (e.g., the network). No, there is not. Can you suggest what that API would look like? Importing keys should be allowed. Something like crypto.pk.importKey(keyBlob) where keyBlob is something like a string containing the keypair in something like PEM format. OK, sounds good Decrypt needs to take a keypair too (or at least a keyid). As the caller of the API, you want control over which of your secrets are used to decrypt the message! Otherwise, you can get it big trouble if you accidentally decrypt with a powerful key. yes. this is something on the back burner that I need to figure out now. It is an object literal that you store discovered public keys in - which are referred to as addressbook entries... Oh man. I'd remove this from the spec. That's a whole other can of worms. This API should just be the nuts and bolts of the crypto. I will, I have been treating this as a separate bug at Moz, and all of the feedback I have gotten is - not yet, not now - consider it removed it will have to be perhaps a part of an identity API of some kind When I use generateKeypair, how long dose the keypair persist? Is are their privacy implications? There is nothing in the spec right now. I should probably use a standard cert type that declares validity dates. This is a very important question. Also, what sites are allowed to use the generated keypair? One hopes just the origin that generated it. You could also ask for something tighter so that some random XSS in one page won't completely compromise all my keys. Yes. The entire API should be gatekept by a geolocation style authorization step. You really need to spell all this stuff out in the spec. What you haven now just completely lacks any details about what these functions actually do. I will, I am a complete newbie to spec authoring, please bear with me as I make all of the changes and Finally, this all should be on the crypto object, not on a new cipher object. More and more people are saying that. Maybe you should listen to them? I am. I think that while all of these details are hashed out it is prudent to keep it separate, but consolidation with crypto is the best bet. This criticism and feedback is great. Thanks again! (keep it coming). David
Re: Request for feedback: DOMCrypt API proposal
- Original Message - From: Jonas Sicking jo...@sicking.cc To: Adam Barth w...@adambarth.com Cc: David Dahl dd...@mozilla.com, public-webapps@w3.org Sent: Friday, June 3, 2011 12:31:48 AM Subject: Re: Request for feedback: DOMCrypt API proposal I agree that keychains and the like seems like a can of worms. However something that we'll eventually will need in some form. I suggest that we punt on this feature for now and leave it for version 2. It can always be kept in the prototype using a 'moz' prefix. Ok, consider it done. I absolutely agree that this needs to live on the 'crypto' property. Introducing new properties on the window object always carries big risks since it shares namespace with global variables. Hence introducing a new property can break pages that have no intention of using the property. This can be mitigated by making the property replaceable, but that only fixes half the problem so isn't really a solution. I did not think about that. Great insight. In this case we have the extremely rare luxury of having a property already existing which not lives where we want it to live (the window object), but also has a pretty good name. So the final implementation should definitely hang the new API off of this property. For prototyping purposes, it's easy to just call the property 'mozCrypto'. That'll let you use the same APIs that you already are to hook it up. Ok, I will do that. Thanks, David
Re: Testing Requirements
Hi Philippe, One more request. I need some way of testing the RFC3490 ToASCII algorithm. In widgets, we are currently using an icann url to do this: access origin=http://हिन्दी.idn.icann.org/ access origin=http://उदाहरण.परीक्षा; subdomains=true/ We basically need some kind of equivalent subdomains to the above.
Re: Request for feedback: DOMCrypt API proposal
- Original Message - From: Rich Tibbett ri...@opera.com To: David Dahl dd...@mozilla.com Cc: public-webapps@w3.org Sent: Friday, June 3, 2011 6:25:15 AM Subject: Re: Request for feedback: DOMCrypt API proposal I wonder whether the problem is actually just one of generating sufficiently cryptographically secure PRNGs or whether there are real benefits to creating a full-blown UA-based Crypto API and the can of worms that might open. With Firefox, we are sitting on top of a well tested, tried and true set of crypto APIs written in C that can be accessed via js-ctypes - and on a worker no less. I think your average web developer needs an elegant API that is using world class crypto under the hood instead of re-building the wheel. naturally, giving JavaScript a secure PRNG would be great. There is a lot of discussion on this subject here: https://bugzilla.mozilla.org/show_bug.cgi?id=322529 Cheers, David
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
--
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 Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
-Ken
[Bug 12883] New: In section headed: Interpreting an event stream Step 4: If the event name buffer has a value other than the empty string, change the type of the newly created event to equal the v
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12883 Summary: In section headed: Interpreting an event stream Step 4: If the event name buffer has a value other than the empty string, change the type of the newly created event to equal the value of the event name buffer. I think you mean change the *name* rathe Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/eventsource/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: In section headed: Interpreting an event stream Step 4: If the event name buffer has a value other than the empty string, change the type of the newly created event to equal the value of the event name buffer. I think you mean change the *name* rather than change the type. Posted from: 76.126.115.158 User agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 -- 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: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect
behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
/ Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only
ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do
this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list
ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect
behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
It's certainly possible - there's nothing intrinsically difficult with
making this change from an implementor's point of view (I've had my fingers
in both the WebKit and Chromium MessagePort implementations so I'm
relatively confident that this would not be prohibitively hard).
Is it desirable? My knee-jerk reaction is that we should stick with changes
that are compatible with the existing API (like Ian's original suggestion,
or adding a separate optional array of transferable objects) - I have no
data on the number of sites that are using the current API but I don't think
we should be changing existing APIs with multiple implementations without
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.
/ Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only
ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do
this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
Right, but you should not write { transfer : frame }, you should write:
postMessage( { frame: frame }, { transfer: frame.histogram })
in this case. The guidance for transferring objects should be: do not
transfer objects you intend to use on this thread (on main thread, worker)
- only transfer parts that you do not intend to use. This version of
postMessage gives a high-fidelity tool for you to do so if desired, but
handles the opaque case as well.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list
ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
(sorry I somehow missed your previous mail when replying)
I do not think filtering by types solve much.
Consider again a case of two library functions compute() returning some data
and present(data) rendering some data, where library user treats the data as
a black box. In first version, library author used ArrayBuffers as part of
data internally, because it is the only data type that is transferrable.
Now, CanvasPixelArray became transferrable as well, and library author
changes the library to compute those as part of the data, to offload more of
the computation to compute phase. With filtering by types, all library
user will need to modify their code as well, to add CanvasPixelArray to a
list of transferrable types in their postMessages.
Again, I think having a transfer list (as some argument to postMessage) is
great solution for high-fidelity control. Low-fidelity, opaque, don't show
me the implementation use cases is what is missing.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
It feels that but not solving this as part of messaging spec we just offload
the complexity to the users.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect
behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
It's certainly possible - there's nothing intrinsically difficult with
making this change from an implementor's point of view (I've had my fingers
in both the WebKit and Chromium MessagePort implementations so I'm
relatively confident that this would not be prohibitively hard).
Is it desirable? My knee-jerk reaction is that we should stick with changes
that are compatible with the existing API (like Ian's original suggestion,
or adding a separate optional array of transferable objects) - I have no
data on the number of sites that are using the current API but I
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 2:25 PM, Dmitry Lomov dslo...@google.com wrote:
(I am answering on multiple points - I do not want to fork the thread)
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only
ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do
this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
Right, but you should not write { transfer : frame }, you should write:
postMessage( { frame: frame }, { transfer: frame.histogram })
in this case. The guidance for transferring objects should be: do not
transfer objects you intend to use on this thread (on main thread, worker)
- only transfer parts that you do not intend to use. This version of
postMessage gives a high-fidelity tool for you to do so if desired, but
handles the opaque case as well.
Right, but we all know that web authors (and us too) quite often have
bugs. Web authors in particular are infamous for using things as long
as they work even if it happens to rely on undefined behavior, browser
bugs, or goes against recommendations in the spec.
The point is that if we allow whole object graphs to be transferred,
we are making it much riskier for ourselves in the future to add
additional transferable types. It does not seem unlikely at all that
we'll end up wanting to make a type transferable but are unable to do
so because a couple of big sites rely on them not to be.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
It feels that but not solving this as part of messaging spec we just offload
the complexity to the users.
Complexity comes in many forms and shapes. I much more like the idea
of explicit APIs that make it clear what happens and make it hard to
shoot yourself in the foot. Yes, it can involve more typing, but if it
results in more resilient code which contains fewer subtle bugs, then
I think we have designed the API well.
/ Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only
ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do
this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list
ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect
behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
It's certainly possible - there's nothing intrinsically difficult with
making this change from an implementor's point of view (I've had my fingers
in both the WebKit and Chromium MessagePort implementations so I'm
relatively confident that this would not be prohibitively hard).
Is it desirable? My knee-jerk reaction is that we should stick with changes
that are compatible with the existing API (like Ian's original suggestion,
or adding a separate optional array of transferable objects) - I have no
data on the number of sites that are using the current API but I don't think
we should be changing existing APIs with multiple implementations without
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.
Drew pointed me off-list to the original discussion motivating the
addition of the optional argument for the array of ports:
http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0001.html
As I've been thinking more about Ian's original proposal, it seems to
me that I might have misunderstood the intent.
The current optional array of MessagePorts is very close to supporting
the semantic of transfer of ownership that is desired. If a
MessagePort is passed in this array, its ownership is transferred to
the other side. The undesirable aspects seem to be:
1) It doesn't seem to be allowed to refer to those MessagePort objects
in the object graph which is the first argument to postMessage. At
least, it looks to me like the structured clone algorithm will throw a
DATA_CLONE_ERR exception if it encounters a MessagePort object.
2) The array of ports shows up on the other side as the ports
property of the MessageEvent.
(1) could be solved, and in a backward-compatible way, by defining the
behavior of MessagePort under structured clone. Cloning a
MessagePort would cause a DATA_CLONE_ERR exception to be thrown, but
if structured clone were taught about the objects to be transferred,
then if a MessagePort were transferred, the cloned object graph could
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 2:54 PM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only
ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the same forwards-compatibility problem. If you do
this:
frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
postMessage({ frame: frame }, { transfer: frame });
and you expect only histogram to be transferred (since that's all that
supports it when you write this code), your code breaks when
CanvasPixelArray later supports it.
b) Transfer lists + separate transferMessage method. We still equip
postMessage with transfer lists, these transfer lists list
ArrayBuffers, and
we provide a separate method transferMessage with recursive transfer
semantics.
What do people think?
Same problem.
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
Agreed on these points. Using an object graph for the transfer list
(which is what the recursive transfer list idea boils down to) also
sounds overly complicated.
May I suggest to reconsider adding another optional array argument to
postMessage for the transfer list, rather than using an object with
special properties?
Points in favor of adding another optional array argument:
1. Less typing, and less possibility that a typo will cause incorrect
behavior:
worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
arrayBuffer2ToTransfer ]);
vs.
worker.postMessage(objectGraph, { transfer: [
arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
2. Possibility of using Web IDL to specify the type of the optional
array argument (i.e., Transferable[]?). Would be harder to do using
an object -- requiring either specifying another interface type with
the ports and transfer attributes, or using any plus
ECMAScript-specific text.
Points in favor of using an object:
1. Could potentially overload the meaning of the optional ports array
argument, avoiding adding another argument to postMessage.
2. More extensible in the future.
Thoughts?
My first thought is that so far no implementer has stepped up and said
that changing the meaning of the 'ports' argument would not be
acceptable. Would be great if someone who is reading this thread and
who works at Google/Apple/Opera could check with the relevant people
to see if such a change would be possible.
It's certainly possible - there's nothing intrinsically difficult with
making this change from an implementor's point of view (I've had my fingers
in both the WebKit and Chromium MessagePort implementations so I'm
relatively confident that this would not be prohibitively hard).
Is it desirable? My knee-jerk reaction is that we should stick with changes
that are compatible with the existing API (like Ian's original suggestion,
or adding a separate optional array of transferable objects) - I have no
data on the number of sites that are using the current API but I don't think
we should be changing existing APIs with multiple implementations without
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.
Drew pointed me off-list to the original discussion motivating the
addition of the optional argument for the array of ports:
http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0001.html
As I've been thinking more about Ian's original proposal, it seems to
me that I might have misunderstood the intent.
The current optional array of MessagePorts is very close to supporting
the semantic of transfer of ownership that is desired. If a
MessagePort is passed in this array, its ownership is transferred to
the other side. The undesirable aspects seem to be:
1) It doesn't seem to be allowed to refer to those MessagePort objects
in the object graph which is the first argument to postMessage. At
least, it looks to me like the structured clone algorithm will throw a
DATA_CLONE_ERR exception if it encounters a MessagePort object.
2) The array of ports shows up on the other side as the ports
property of the MessageEvent.
(1) could be solved, and in a backward-compatible way, by defining the
behavior of MessagePort under structured clone. Cloning a
MessagePort would cause a DATA_CLONE_ERR exception to be thrown, but
if structured clone were taught about the objects
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing changes, so postMessage(..., [ports]) is equivalent to
postMessage(..., {ports: [ports]}). (The array-only approach can be
done compatibly, too; the object version is just an alternative to
that.) What's backwards-incompatible?
On Fri, Jun 3, 2011 at 5:25 PM, Dmitry Lomov dslo...@google.com wrote:
If you want a quicker way to transfer all messages of given types, see
my previous mail: { transfer: ArrayBuffer }.
(sorry I somehow missed your previous mail when replying)
I do not think filtering by types solve much.
It solves the very large transfer list performance question, though
it hasn't been shown whether that's an actual problem. It also allows
writing functions like postMessageTransfer(port, obj) {
port.postMessage(obj, { transfer: [ArrayBuffer] }); }, without having
to do the recursion yourself to find the ArrayBuffers.
(Dmitry: I'm receiving each of your mails twice; once from
dslo...@chromium.org and once from dslo...@google.com.)
On Fri, Jun 3, 2011 at 5:54 PM, Kenneth Russell k...@google.com wrote:
b) Leave the MessagePort[] ports property. Filter out all
MessagePorts from the incoming Transferables[], and have only them
show up in the ports array on the other side.
FYI, this is the same as what I described earlier.
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0812.html
(second paragraph)
On Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
e) Keep MessagePort[] ports the way it is but deprecate it.
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value deprecate has on the web) the
ports array in MessageEvent--not the ports parameter to postMessage
(that's a sequence).
I agree that it'd be great to be able to pass MessagePorts around like
other objects. I havn't had to use them with any complexity yet, but
the current mechanism seems cumbersome for moving more than one port
around at a time.
--
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 Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote: e) Keep MessagePort[] ports the way it is but deprecate it. For anyone not looking closely at the IDL while reading this, this means deprecating (for whatever value deprecate has on the web) the ports array in MessageEvent--not the ports parameter to postMessage (that's a sequence). I agree that it'd be great to be able to pass MessagePorts around like other objects. I havn't had to use them with any complexity yet, but the current mechanism seems cumbersome for moving more than one port around at a time. In this case, deprecating would mean that browsers that hasn't implemented the property yet wouldn't do so. And if they wanted to, browsers that do implement it could add a warning in the developer console any time the property is used and eventually remove the property once it seems likely that people have stopped using it. / Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API
don't
seem compelling to me given the existence of backwards-compatible
alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing changes, so postMessage(..., [ports]) is equivalent to
postMessage(..., {ports: [ports]}). (The array-only approach can be
done compatibly, too; the object version is just an alternative to
that.) What's backwards-incompatible?
Ah, I missed that piece (to be honest, I haven't been following this
discussion in every detail - I only chimed in because of Jonas' request for
implementation feedback).
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value deprecate has on the web) the
ports array in MessageEvent--not the ports parameter to postMessage
(that's a sequence).
Does this affect the API for the SharedWorker onconnect message as well?
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API
don't
seem compelling to me given the existence of backwards-compatible
alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing changes, so postMessage(..., [ports]) is equivalent to
postMessage(..., {ports: [ports]}). (The array-only approach can be
done compatibly, too; the object version is just an alternative to
that.) What's backwards-incompatible?
Ah, I missed that piece (to be honest, I haven't been following this
discussion in every detail - I only chimed in because of Jonas' request for
implementation feedback).
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value deprecate has on the web) the
ports array in MessageEvent--not the ports parameter to postMessage
(that's a sequence).
Does this affect the API for the SharedWorker onconnect message as well?
Good point; that might inform not deprecating the ports array in
MessageEvent, but leaving it as is.
-Ken
