W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[WebIDL] "module" in ECMAScript

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Fri, 29 May 2009 11:56:30 +0200
To: public-webapps <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C0A26ED8F75@OBEEX01.obe.access-company.com>
Hi All,

The BONDI specs [1] are defining a few WebIDL modules for accessing device APIs from the JavaScript.
Based on the specs [2] I have created the full WebIDL [3] for all BONDI 1.0 definitions.
The specs [2] are derived from the WebIDL module definitions as described in [4].
BONDI API specifications assume that the API definitions may change in the future, and that was the reason to introduce versioning [5].
In [6] you can see how the BONDI API are used, based on the sample code for FIleSystemManager.resolve method.

In BONDI WebIDL we implicitly assumed that "module" definition is mapped to the interface naming.
Thus bondi.filesystem.* is available without explicit creation of the "filesystem" property of the "bondi" object.
This implicit creation of property may result from the definition of submodules, as in [3].
However, this is just an incorrect interpretation of the WebIDL for ECMAScript that resembles bindings of WebIDL in Java [7]. The WebIDL "module" has no meaning in ECMAScript [8]:
"In the Java language binding, the name of the Java package is derived by taking the prefixed name  and replacing occurrences of "::" with "." (see section 5.3). The ECMAScript language binding does not have a namespacing mechanism, and thus does not use a module's prefixed name."
[9] says that:

"For every interface that is not declared with the [NoInterfaceObject]  extended attribute, a corresponding property MUST exist on the ECMAScript global object whose name is the identifier of the interface. The value of this property is an object called the interface object, which provides access to the constants  and operations defined on the interface."

In BONDI, however, we do not want the interfaces to be available under the global object. This is visible also from the sample code for constant usage [10]:
        try {
                // gets current night mode
                var night_mode = camera.getFeatureValue(bondi.camera.Camera.NIGHT_MODE);
                // Switch on nightmode
                camera.setFeatureValue(bondi.camera.Camera.NIGHT_MODE, true);
        catch(e) {

The similar mechanism for property definition is used in Google Gears.
In Google Gears (e.g.[13]) we can see that the subclasses are properties of google object.
E.g. google.gears means that there is "google" object that has "gears" property. "gears" is an object itself. Gears uses factory method to create those structures [14].
The "google" and "gears" objects are defined only in order to have well-structured naming conventions.
Subclassing in Gears may resemble "module in module" definitions in WebIDL, but frankly speaking I did not find anywhere an example of "module in module" binding in ECMAScript.

In HTML5 the interfaces are available under the global object and interfaces are available as properties to create hierarchical structures. E.g.
window.locationbar.visible [11] is possible, because locationbar is an attribute of the Window interface [12].

In BONDI we are now planning to clarify that the module within module definition has the semantics of the submodule being an attribute for the enclosing module. Naming structure is still under discussion.
E.g. we could have
module bondi {
        module pim {
                module task {
to be equal to:

interface TASK {

interface PIM {
        attribute TASK task;

interface bondi {
        attribute PIM pim;
but with the above we still may have problems with the constants, I think.

a) Is any further standardization planned for refining of the semantics of the "module" within ECMAScript?
We could foresee here something like automatic generation of the property/attribute for submodules or similar text.
I would be grateful for any clarification or pointing to some archives if the above topics has been discussed already in the past.


Kind regards,

[1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0641.html
[2] http://bondi.omtp.org/1.0/apis/index.html
[3] http://bondi01.obe.access-company.com/1_0_3309_41/webidl_clickable.html
[4] http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#moduleformat
[5] http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#versioning
[6] http://bondi01.obe.access-company.com/1_0_3309_41/filesystem.html#ifFileSystemManager_mthresolve
[7] http://dev.w3.org/2006/webapi/WebIDL/#java-modules
[8] http://dev.w3.org/2006/webapi/WebIDL/#idl-modules
[9] http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces
[10] http://bondi01.obe.access-company.com/1_0_3309_41/camera.html#ifCamera_cstNIGHT_MODE
[11] http://dev.w3.org/html5/spec/#browser-interface-elements
[12] http://dev.w3.org/html5/spec/#the-window-object
[13] http://code.google.com/intl/pl/apis/gears/gears_init.js
[14] http://code.google.com/intl/pl/apis/gears/api_factory.html

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Friday, 29 May 2009 09:57:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC