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

RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

From: Kruessel, Steffen <Steffen.Kruessel@fokus.fraunhofer.de>
Date: Tue, 30 Jun 2009 09:54:28 +0200
Message-ID: <79C0EA6E7AD7CE4A85EDAF482B5456B202233A4E@EXCHSRV.fokus.fraunhofer.de>
To: "Marcin Hanclik" <Marcin.Hanclik@access-company.com>, "Cameron McCormack" <cam@mcc.id.au>
Cc: "WebApps WG" <public-webapps@w3.org>
Hi Marcin, Hi Cameron,

My name is Steffen Krüssel and I am participating in the BONDI initiative, especially in the interface specification for camera and geolocation. Regarding your conversation about the current geolocation IDL, I just want to clarify the meaning of the [Callback] extended attribute, as for me the description in the current WebIDL specification is still not clear.

Why do we have to extend the "datatype interface" PositionOptions (which only provides input data for a function, e.g., getCurrentPosition()) with [Callback]? PositionOptions will not be "called back" by the getCurrentPosition() implementation, but rather provides complex input data (i.e. attributes on the given object).

[WebIDL]:"If the [Callback]  extended attribute  appears on an interface, it indicates that the interface can be implemented by an ECMAScript native object (see section 4.5  below), and such an object can be passed to a host object expecting an object that implements the interface."
Must the PositionOptions object be an "ECMAScript native object" and what are the cutbacks if it would not? Perhaps you can give a short example on the impact of not extending the given interface with [Callback]?!

Thank you both in advance

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Marcin Hanclik
Sent: Friday, June 26, 2009 10:26 AM
To: Cameron McCormack
Cc: WebApps WG
Subject: RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

Hi Cameron,

Thank for your comments.
It is clear now.

>>I’ll probably loosen the IDL grammar to allow
>>sequences of square-bracketed extended attributes instead of requiring
>>them to be all in one, but for now you do need to have them all in one,
>>comma separated.
As for me it is not necessary to loosen the IDL grammar.
Listing the extended attributes separately was my problem within the example and I am sorry for that.
Stability of the spec seems important.


Kind regards,

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

-----Original Message-----
From: Cameron McCormack [mailto:cam@mcc.id.au]
Sent: Friday, June 26, 2009 2:51 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

Marcin Hanclik:
> Following our conversation on the geolocation ML
> http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html

> I have the following clarification request related to the Web IDL spec.
> In the geolocation spec we have now:
>   [NoInterfaceObject]
>   interface PositionOptions {
>     attribute boolean enableHighAccuracy;
>     attribute long timeout;
>     attribute long maximumAge;
>   };
> Proposed and agreed in our mail discussion:
>   [Callback]
>   interface PositionOptions {
>     attribute boolean enableHighAccuracy;
>     attribute long timeout;
>     attribute long maximumAge;
>   };
> Our intentions are:
> 1) Not to instantiate the interface object with new PositionOptions();
> This is handled by not specifying [Constructor] extended attribute.
> 2) Not to have PositionOptions on the ES global object.
> This shall be handled by specifying [NoInterfaceObject]. But it
> seems to have to be removed.
> 3) Use PositionOptions interface to specify properties of the object
> passed to e.g. getCurrentPosition() method.
> This is handled by specifying [Callback].
> 4) Resulting from the above, use the PositionOptions as follows:
> navigator.geolocation.getCurrentPosition(successCallback,
>                                              errorCallback,
>                                              {maximumAge:600000});


> Questions:
> a) What is the PropertyOnly argument/identifier for?
> It seems unclear from the Web IDL spec.
> Does it specify that the interface has one attribute only and ES
> binding just one property?
> Or does it specify that the interface includes only attributes?
> Or does it signify only the opposite to FunctionOnly?

I’ll try to clear up the wording in

The intended meaning of [Callback=PropertyOnly] is that if the interface
has one or more operations with the same name (but no others) and no
attributes, then an ECMAScript Function object’s [[Call]] will not be
considered to be the implementation of those operations.  Instead, the
[[Call]] of the object returned from invoking [[Get]] with the operation
identifier as the property name will be.

So for example with these interfaces:

  interface Target {
    void registerListener(in Listener x);

  interface Listener {
    void f();

this would work:

  getTarget().registerListener(function() { … })

as would:

  getTarget().registerListener({ f: function() { … } });

If [Callback=FunctionOnly] was specified, then only the former would
work (passing a Function object), while if [Callback=PropertyOnly] was
specified, then only the latter would work.

Web IDL really should make IDL fragments non-conforming to use
FunctionOnly or PropertyOnly when the interface has operations of
different names or when it has attributes.

> b)
> Shouldn't we have the PositionOptions specified as follows?
>   [NoInterfaceObject]
>   [Callback=PropertyOnly]
>   interface PositionOptions {
>     attribute boolean enableHighAccuracy;
>     attribute long timeout;
>     attribute long maximumAge;
>   };

It should be:

  [NoInterfaceObject, Callback]
  interface PositionOptions {

as far as I can tell.  (I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.)


Cameron McCormack ≝ http://mcc.id.au/


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 Tuesday, 30 June 2009 12:56:24 UTC

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