| 03:21 | <annevk> | abarth: RemoteDocumentMessaging can be done through localStorage |
| 03:21 | <abarth> | yes, but that has bad performance |
| 03:21 | <annevk> | abarth: not exactly ideal because of synchronous IO, but might be worth studying how people use that today |
| 03:22 | <annevk> | abarth: I added a pointer to the wiki which has further pointers |
| 03:22 | <abarth> | thanks |
| 03:23 | <annevk> | hahaha: http://www.google.com/patents/US7730419 |
| 03:24 | <annevk> | http://www.google.com/patents/US7426699 if you can patent that kind of stuff... geez |
| 03:30 | <abarth> | annevk: do you other thoughts on the proposal? |
| 03:31 | <annevk> | abarth: I'm a bit worried that we made workers so costly and not good enough API-wise that we're instead inventing things like event pages and such (for which I imagine this is meant as well) that do not exactly lead us towards a better parallel world |
| 03:33 | <annevk> | abarth: it's kinda orthogonal in a way I suppose, but we should really start figuring something out there |
| 03:33 | <abarth> | i'm not sure I understand. i guess you're saying that you'd prefer if we found a way for workers to use less resources? |
| 03:33 | <abarth> | event pages seem somewhat unrelated to me |
| 03:33 | <abarth> | we could make shared workers have a "wake me up when needed" semantic |
| 03:34 | <annevk> | Well, event pages need a way to communicate with other windows... I was kinda hoping event pages for the web could just be workers, but it seems like workers are not ready yet for that :/ |
| 03:35 | <abarth> | why can't event pages just use message ports, like workers? |
| 03:35 | <abarth> | i guess it depends on how they're created |
| 03:36 | <abarth> | because the worker is created by a page, the page has a JS interface that has a message port hanging off of it |
| 03:36 | <abarth> | so, it's more about the creation mechanism than about unicast versus multicast |
| 03:36 | <annevk> | fair enough, but I thought workers was our solution for things not running on the main thread |
| 03:37 | <abarth> | in Chrome, we have many main threads, one per process |
| 03:37 | <annevk> | sure |
| 03:37 | <abarth> | BroadcastChannel lets them communicate |
| 03:38 | <abarth> | iirespective of event pages |
| 03:38 | <annevk> | I understand all that. As I said, my concern is kinda orthogonal |
| 03:38 | <annevk> | Something like broadcastchannel makes sense to have. |
| 03:38 | <abarth> | ah ok |
| 03:39 | <abarth> | my understanding is that reason the extension folks chose event/background pages rather than workers |
| 03:39 | <abarth> | is because they wanted them to be able to build DOM |
| 03:39 | <abarth> | and present that DOM in UI surfaces, like balloons |
| 03:40 | <abarth> | I'm not sure how many extensions actually do that |
| 03:40 | <abarth> | in that sense, they're on the main thread |
| 03:40 | <annevk> | What I heard was 1) more APIs available 2) workers require too much resources |
| 03:41 | <abarth> | workers require fewer resources than HTML documents |
| 03:41 | <abarth> | more API -> the ability to build DOM |
| 03:41 | <annevk> | I think the way workers are implemented they're more costly than running another thing on the main thread. |
| 03:41 | <annevk> | Which is rather sucky :( |
| 03:41 | <abarth> | in chrome or in other browsers? |
| 03:42 | <abarth> | that was true in the original implementation in chrome |
| 03:42 | <annevk> | Both Chrome and Firefox? |
| 03:42 | <annevk> | Oh |
| 03:42 | <abarth> | but we've fixed that :) |
| 03:42 | <annevk> | I think we might have regressed |
| 03:42 | <abarth> | we didn't use to be able to run multiple JS threads in the same process |
| 03:42 | <abarth> | but we can now |
| 03:42 | <annevk> | cool cool |
| 03:43 | <abarth> | dedicated workers, however, are very rarely used |
| 03:43 | <abarth> | essentially all workers are shared workers |
| 03:43 | <abarth> | at least according to usage stats |
| 03:43 | <annevk> | interesting, I think we might have just landed support for shared workers |
| 03:44 | <annevk> | hmm I need to go, I think it's boarding time |
| 03:44 | <annevk> | thanks for the chat |
| 03:44 | <abarth> | have a good flight |
| 03:44 | <abarth> | thanks for the feedback |
| 17:29 | <zcorpan> | Hixie: should this be marked as FINGERPRINT?: |
| 17:29 | <zcorpan> | + <li><p>Let <var title="">message</var> be a user-agent-defined |
| 17:29 | <zcorpan> | + string describing the error in a helpful manner.</p></li> |
| 17:30 | <zcorpan> | (maybe that should be fleshed out so we get interop on the message?) |
| 18:16 | <GPHemsley> | annevk: Please review: http://wiki.whatwg.org/index.php?title=Contexts&oldid=9195 |
| 18:19 | <GPHemsley> | annevk: Actually, better link: http://wiki.whatwg.org/index.php?title=Contexts&diff=9195&oldid=9180 |
| 18:33 | <GPHemsley> | Hixie: Can you elaborate on how javascript: URLs are used in <img> elements? http://www.whatwg.org/specs/web-apps/current-work/#javascript-protocol |
| 19:08 | <gsnedders> | jgraham: I suspect r/103 is just you having missed comments on a issue you raised |