Re: [xml-dev] Open Platform

[Henri Sivonen <hsivonen@iki.fi>]

On Dec 13, 2010, at 06:30, Michael Kay wrote:

> In broad terms, I mean a platform that allows anyone to implement new software to run on that platform, without unreasonable restrictions. As a minimum, that includes the provision of a virtual machine which can be reasonably used as a target for compiling or interpreting a wide range of programming languages and their run-time libraries.

JavaScript is that compiler target and the WebIDL-exposed APIs are the standard library.

> And despite Google's heroic efforts with GWT, I don't think Javascript qualifies as such a VM. Having to implement 64-bit integer arithmetic by software emulation using a pair of doubles is just too convoluted; and the concurrency model seems to be pretty limiting too.

I think intuitively it seems really weird to conclude that a platform is not "open" based on its integer arithmetic or concurrency characteristics. I'd consider those characteristics to be on different axes than openness.

When considering using JS as a compiler target as opposed to writing JS by hand, it shouldn't be a great concern how the JS-targeting compiler manages to do 64-bit integer arithmetic, since any complexity is hidden by the compiler.

Historically, browsers were single-threaded, which lead to the task queue model. Web Workers are rather recent, and when they were developed, shared-memory threads were explicitly rejected. Shared memory isn't a great way to handle concurrency. It's all too easy to get things wrong with shared memory. No shared memory plus message passing is a safer model for concurrency. The downside is data copying when different threads of execution need to communicate. Even if one deems the task queues and message passing limiting, it seems odd to say the model makes the platform not open. (Is Erlang not an open platform?)

> Security restrictions in terms of what resources are accessible are of course reasonable, though as far as I can see the cross-site-scripting rules seem to be about as relevant to the real threat model as the theatrical checks performed in airport security halls.

Could you, please, elaborate? How is the Same-Origin Policy not relevant to the threat of information leakage when the browser has ambient authorization to access private data from another origin?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/