On Mar 4, 2011, at 8:39 AM, Mark S. Miller wrote: > I certainly agree that there needs to be a better interface boundary > between w3c/whatwg specs and ECMA specs. Too many issues -- like the > semantics of multiple globals -- fall in the gaps between the two > organizations. The WebIDL's JS binding and public-script-coord are good > places to work out these boundary issues. WebIDL, WebIDL's JS binding, and > ES-next should co-evolve so that the rest of the w3c/whatwg specs ideally > interface to JS only through WebIDL, and WebIDL's JS binding ideally depend= > s > only on standard elements of ES-next. Of course, there will always be a nee= > d > to accommodate some special cases that can't be specified that way, like th= > e > "semantics" of cross-origin heap sharing. > > My main regret in saying this is that WebIDL, having evolved from Corba IDL= > , > is notationally almost pessimal for encouraging good JS interface design. W= > e > have all been suffering the consequences of that. I fear that WebIDL, and > its entrenched place within the w3c/whatwg API design process, dooms us to = > a > continual flood of browser APIs hostile to JS programmers.
I also agree that there are issues here that need a common resolution. However, it is less clear to me that that WebIDL is the best (or only) place it needs to be addressed. WebIDL defines how abstract interface definitions map to the concrete features of various languages. However, there are places in web specifications where specific semantic actions (not interfaces) must be described in a manner that that transcend all languages. These are not "language binding" issues, but rather concerns that relate to the semantics that must be commonly support by any language that executes in the web application environment. Essentially, there is a language independent web apps scripting environment. More concretely, you might think of this as the common shared browser heap. This environment should be specified in or as one of the core browser/web app specifications. If that is done, then "language bindings" can be specified the context of that specification. Some of characteristics of this scripting environment may include things like: Web app objects encapsulate state that may include reference to other objects. The state of objects can be manipulated/access via put/get/call operations to their methods and attributes. There are multiple independent heaps. Heaps have well defined lifetimes. Each object exists within a specific heap and has unique identity with respect to its heap. Objects within a common heap may directly reference and interact with each other, constrained only by their specific language semantics. References between objects in different heaps must be intermediated via a mechanism with a specified semantics. Multiple "Script global objects" may exist in a single heap. etc. The specification of this environment should sufficiently complete that all language independent scripting characteristics of the browser (for example cross-origin policies) to be specified strictly in terms of that specification and without references to any specific language binding. Done well, this would give us a much cleaner separation between the "web app" platform and specific scripting language. At that point, some of the issues of current concern then really do become "language binding" issues. For example, how does the concept of multiple "Script global objects" map onto the ECMAScript language.
