[Bug 23900] New: WebRTC DataChannels are not called out as producers/consumers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23900 Bug ID: 23900 Summary: WebRTC DataChannels are not called out as producers/consumers Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Streams API Assignee: tyosh...@google.com Reporter: feras.mou...@hotmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org We should consider what role DataChannels plan in the Streams API, and integrate them accordingly. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Sync IO APIs in Shared Workers
On Nov 23, 2013 2:04 PM, "David Bruant" wrote: > > Le 22/11/2013 03:33, Jonas Sicking a écrit : >> >> We could enable sync IO APIs in workers while still allowing the >> worker thread to remain responsive to messages from the main thread. >> One solution is the API in [2]. Using that API the main thread can >> send a error-response to a sync request for IO before the IO has >> finished. >> >> [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html > > I'm not sure I understand this proposal. If you allow messages from main thread while waiting for I/O, aren't you re-introducing the same complexities that sync APIs are expected to stay away from? No, because the main thread can always "return early" and not wait for the result from the IO before sending a message. / Jonas
Re: Sync IO APIs in Shared Workers
Le 22/11/2013 03:33, Jonas Sicking a écrit : We could enable sync IO APIs in workers while still allowing the worker thread to remain responsive to messages from the main thread. One solution is the API in [2]. Using that API the main thread can send a error-response to a sync request for IO before the IO has finished. [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html I'm not sure I understand this proposal. If you allow messages from main thread while waiting for I/O, aren't you re-introducing the same complexities that sync APIs are expected to stay away from? What about providing both APIs in workers? sync and async. This way, everyone can get what they want. There is something ugly in providing both, but Node.js did it and is doing fine. And the sync version would be uncompromised. For authors, it would then be a matter of making a choice, understanding the pros and cons of this choice and accepting them. David
Re: [HTML Imports]: what scope to run in
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking wrote: > > > It would technically be possible to define that
Re: [HTML Imports]: what scope to run in
On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking wrote: > At the very least, I would like to see a way to write your > HTML-importable document as a module. So that it runs in a separate > global and that the caller can access exported symbols and grab the > ones that it wants. We had a brain-storming session about this today and I offered to write up the conclusions. Confusion was abound about how various details of ES6 modules work, in part because not all corner cases have been nailed down yet, or at least have been nailed down so recently that the message hadn't reached everyone yet. Our conclusion was as follows: We want HTML imports to use the same mechanisms for dealing with name collisions and module reuse as much as possible. ES6 currently allows importing modules using both URLs and names. When a names (rather than URLs) are used, there is a risk of collisions. Specifically when a document imports two ES6 modules, A and B, both expect a module named "apple" to be available, but expect that the name "apple" maps to two completely different libraries. To resolve this ES6 uses a hook which is given enough context as to allow the the name "apple" to map to two different modules in A and in B. We concluded that as long as ES6 only allows referring to module names added higher up in the original document there is no race condition. (In hindsight it's unclear to me that this was still a requirement once we got to the end of the discussion). We concluded that ES6 needs to use different names when referring to a module by URL vs. by name. Otherwise it would be impossible for the HTML prescanner to fire off network requests eagerly which is important for performance. This does not seem to require changes to ES6, but it does require consideration when defining how the built-in resolver hook in browsers should behave. We should make it a recommendation that HTML pages use elements rather than
Re: RTC in Web workers
I asked for this several months ago on the W3C public-WebRTC mail list ( https://groups.google.com/forum/m/#!msg/discuss-webrtc/1hnewM6xxf8/nzNg6tcxC6wJ), and the final answer was that we should wait until the specification was more stable before going into more problems. Since now Chrome & Firefox are interoperable with audio & video and with DataChannels (with some problems for big data, but small messages of some kb can be exchanged) I think now it's the moment to start talking about it. I would like to be able to have it working specially on SharedWorkers and ServiceWorkers ( https://github.com/slightlyoff/ServiceWorker ). Send from my Samsung Galaxy Note II El 23/11/2013 08:22, "Charles Pritchard" escribió: > Should RTC data channels be available in Workers and/or SharedWorker? > > Mainly: > self.RTCPeerConnection > self.RTCSessionDescription > > WebSocket and XHR are available, seems like RTC ought to be but isn't. > > -Charles > > >
