franksalim

You can have SVG layers in OpenRaster. See: http://freedesktop.org/wiki/Specifications/OpenRaster/Draft/...

They are using the Allwinner A10. You ought to have some luck: http://rhombus-tech.net/allwinner_a10/ (See the source and kernel sections.)

The TCP proxy use case, which has been my primary motivation for WebSocket since day one, points to another limitation of SSE. SSE cannot handle binary data without encoding the data into text. WebSocket can.

I'm surprised the author didn't jump on this sentence:

"With any diagnostic data sent to Apple, customers must actively opt-in to share this information..."

As I understand it, Carrier IQ is about sending data to carriers. Apple only denied that data was silently sent to Apple. That's completely different than saying no data has been transmitted at all.

Last thing first: TCP requires a listening server. WebSocket requires a listening server. There is not inherently more infrastructure required.

The handshake and HTTP upgrade are there for a reason. Connecting out from web applications with straight TCP breaks the web security model. After the handshake, you can treat WebSocket binary frames as if they were a TCP byte stream. Speak any protocol you want to.

Anything you can do with TCP you can do with WebSocket. The only exception is that you cannot connect to a listening server that does not expect the WebSocket handshake. That is intentional! In fact, that is the reason for the WebSocket handshake.

What use cases for TCP do you envision where WebSocket won't be sufficient? It is quite possible to speak standard protocols over WebSocket that are typically spoken over TCP.

Or a URL.

That's what I expected, too. It could be possible in the future with CSS shaders or filters. http://www.adobe.com/devnet/html5/articles/css-shaders.html

That's probably because the DOM's window.location.protocol returns "http:" for URLs with http schemes. That is reflected in the diagram included in the article where protocol extends to cover the colon in the DOM row. Overall, it's a pretty unfortunate mish mash of terminology.

Go differs on points 3,4,6, and 8. That's only 50%. I think it doesn't sound much like Go.

Those are searches for the string MSFT. The article uses the share price data that the author uploaded. See how the chart is labeled "User uploaded activity for MSFT and US Web Search activity for google interview questions."

And x years down the line we'll see "so you think you own your domain name?" Actually, we've already seen articles like that. It's just more difficult (but not impossible) to lose your domain name for trademark reasons.

You can, however, open a WebSocket. You won't be able to connect directly to an SSH server listening with TCP, but you can connect to a server speaking SSH over the WebSocket Protocol. Of course, you can do that today with JavaScript. Ten year old network protocols do not require native code for performance.

Your current license key is usually for an OEM version and not a "full retail copy." I understand this as meaning you will have to purchase Windows 7 again if it came pre-installed on your PC.

I would say it is about as different as Dalvik is.

Saw this by chance on twitter:

http://twitter.com/BillGates/status/19764971764 "I’ve been spending time watching some of the courses on www.khanacademy.org – many of which are quite good. More coming on GatesNotes..."

For what it's worth, I think he is right. You can learn a tremendous amount by reading and watching talks on the Web.

That sounds like this story: http://www.dadhacker.com/blog/?p=935 I would like to know the name of the company or hear more war stories.

I cannot disagree enough.

There are plenty of JavaScript compilers that each have their own incompatible module systems. Adding another will only exacerbate what is already a major problem. JavaScript needs modules in the language to prevent fragmentation into what are effectively different source languages.

I think that is due to OpenAMQ and not AMQP the protocol. sudo apt-get install rabbitmq-server will get you a working AMQP server on Debian or Ubuntu in one step. Building from source is fairly easy, as well: http://www.rabbitmq.com/build-server.html

WebSockets: 1. Can use TLS 2. The client always initiates the connection 3. Can be use the same API with a shim or comet underneath

The origin header represents the origin of the script initiating the request. The location is the address of the server. These can be different. By acknowledging the origin of the request, the server explicitly grants access to that origin.

This is similar to the origin model for cross-origin XHRs (http://www.w3.org/TR/access-control/#access-control-allow-or...).

WebSockets have been capable of cross-origin communication since day one. (see: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...) "The |WebSocket-Origin| header is used in the Web Socket handshake. It is sent from the server to the client to confirm the origin of the script that opened the connection. This enables user agents to verify that the server is willing to serve the script that opened the connection."

Hi, Many of the comments here are negative, probably due to the overly sensational title ;-) Since this is a project I have been working on, however, I will do my best to clarify and respond candidly.

This is clearly not a breakthrough. Sockets (or socket-like interfaces) are the most obvious way to communicate a bi-directional stream of bytes. This has been true for decades. The problem is that everybody has been trying to reinvent the wheel for AJAX. So yes, this is not new, just something that had been missing from the web for a long time!

We have been very mindful of the security implications. Orbited uses a strict whitelist and will not allow outgoing connections to addresses (hostname:port) that are not listed in the access configuration.

Feel free to ask me any questions.

-Frank Salim