XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Open Platform

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/




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS