Hi All,
Introduction:
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.
Motivation:
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) {
alert(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.
Question:
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.
Thanks.
Kind regards,
Marcin
[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: [email protected]
________________________________________
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
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.
