[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Open Platform

  • From: Henri Sivonen <hsivonen@iki.fi>
  • To: "xml-dev@lists.xml.org List" <xml-dev@lists.xml.org>
  • Date: Mon, 13 Dec 2010 17:06:03 -0800

Re:  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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.