2:27 PM <jscott> Hey Hixie, I was discussing cross-origin web workers with sicking and they said that you might be able to explain an interesting design decision to me
2:27 PM <jscott> Web workers don't use CORS although the dev docs ambiguously imply that they might and from a user experience point of view it seems like they should
2:28 PM <Hixie> hey
2:28 PM <Hixie> workers are designed so that once browsers have acutally implemented the spec as it is today, we can add cross-origin workers
2:28 PM <Hixie> the way it'll work is that the script would run within the security context of the remote origin
2:28 PM <Hixie> not the source origin
2:29 PM <Hixie> but right now browsers have barely done even the basics of what the worker spec already says, so i haven't added such fancy features yet
2:29 PM <jscott> Haha, I figured it would come down to that
2:30 PM <jscott> If you don't mind explaining it, what might it look like once it's done? I have a worker running on A, I want to attach it to a library I'm running on B, what's the bridge if not a cross-origin resource call?
2:31 PM <jscott> rather a worker hosted on A
2:33 PM <Hixie> var b = new Worker('http://otherorigin.example.com/b.js");
2:33 PM <Hixie> browsers fetches b.js with CORS to ensure that that origin is ok with this
2:33 PM <Hixie> though probably not exactly CORS
2:33 PM <Hixie> because we want to get execution rights, not reading rights
2:34 PM <jscott> So sort of an extension on CORS, maybe another header
2:34 PM <Hixie> and then a worker is created that is in http://otherorigin.example.com:80's origin