+1 Jonas.
Though a bit off-topic. Robert's Audio (and by all obvious means, video/canvas/pixel) workers preserve this trust across all routes. Unfortunately for developers, there is a lacking trust with vendors in exposing low-level audio-visual-spatial-semantic APIs for sandboxed communication. (also off-topic). Summary: realtime threads existed and are spec'ed in a simple proposal. They're a specialized instance of web workers. Also, opinions exist about web apps and security. On Aug 11, 2012, at 8:48 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Sat, Aug 11, 2012 at 3:22 PM, Jussi Kalliokoski > <jussi.kallioko...@gmail.com> wrote: >> On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard <gl...@zewt.org> wrote: >> >>> On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski < >>> jussi.kallioko...@gmail.com> wrote: >>> >>>> On W3C AudioWG we're currently discussing the possibility of having web >>>> workers that run in a priority/RT thread. This would be highly useful for >>>> example to keep audio from glitching even under high CPU stress. >>>> >>> >>> Realtime work is hard in a nondeterministically GC'd environment. >>> >>> Be careful about a flag that says "run this thread at higher priority". >>> People will simply always set it; it makes their code run faster (at the >>> expense of other pages' workers, who they don't care about). >>> >> >> I'm not sure what that claim is based on, in native applications the >> process priority hardly ever (haven't seen once, actually) gets abused. The >> only place where high priority really makes sense outside the main thread >> (which we won't allow) is time-critical threads, such as audio processing >> or a physics engine. > > The security model for native applications is different from the > security model for the web. > > When running a native application on most contemporary operating > systems, you are trusting that application to behave well. I.e. you > trust it to not read private data from your computer and send it to a > remote location. You trust it to not use system resources to send spam > emails. You trust it to not install backdoors and hand control over > your computer to other people. > > This isn't generally true with web applications. People often end up > running web applications that they don't trust in the least. They just > clicked a link in an email or on a search result page. They still > expect none of the above things to happen, but not because the pages > that they end up on won't attempt to do it, but because the browser > will prevent any of the above from happening. > > / Jonas
