Rick Waldron has detailed the SharedWorker support that Opera has added in 10.6 beta (and has been available in Safari 5 and Chrome 5).
Web Workers are fantastically simple. Simple message passing. No thread locks and semaphores and craziness. However, not being able to share a thing as a constraint is painful, and a nice addition to the spec is the notion of a SharedWorker:
Instead of a single message processing function, workers can attach multiple event listeners, each one performing a quick check to see if it is relevant for the message. If multiple authors wanted to collaborate using a single port to communicate with a worker, it would allow for independent code instead of changes having to all be made to a single event handling function.
To get the Gist of it, Rick put together some GitHub goodness to exemplify the new world:
Basic HTML page for running the test:
The HTML page called in the iframe:
The Renderer (that’s your browser window)
The SharedWorker
This demonstrates how we can connect two different pages to the same SharedWorker process, and track our connections to them from one persistent object variable. Very exciting!
The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.
Salt and Pepper indeed. A friend at a browser vendor was looking into Pepper and thought that the specs were definitely….. thorough shall we say? Take Pepper Audio by itself. A bit of a beast! :)
It is interesting to watch Google give C/C++ developers (and legacy code) a different path to the Web (beyond NPAPI and… ActiveX!). You can imagine this being increasingly important when you think about Chrome OS.
Ideally, the Web platform itself evolves fast enough that this project is always an onramp for legacy code…. what do you think?
Mark Pilgrim continues to create fantastic content for his Dive Into HTML5 book. His latest is on HTML extensibility.
Some folks tried to get us to use RDFa in XHTML (and try to get us doing it in HTML5 too… :/), and we have had the micro-formats folks take a pragmatic approach.
Position any element relative to any other, or even relative to the window or the mouse. In true “Write Less. Do More” fashion, it’s a simple as selecting the element you want and saying which part of it should be positioned relative to which part of another element. Bam.
The button widget creates a themable button from any imaginable element you might be using as a native button. Progressive enhancement all the way. Now your
Now you can make any text input pop up a menu to aid the user in completing a text entry or search box, providing suggestions or allowed values. The autocomplete is designed and built based on the popular Jörn Zaefferer’s Autocomplete. As with the button widget we’ve kept the API as minimal as possible while providing the hooks necessary to customize it based on your needs. For example, you can provide static local data using the source option, or provide a callback function as the data source which can handle getting data from a server via Ajax. Single option, overloaded. This is the new way we’ll be writing and refactoring all of our widgets going forward, and we’re excited to hear what people think. It’s quite a change, but should keep the library lean while still as flexible and powerful as possible.
