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

Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Tue, 30 Jun 2009 15:38:00 +0200
Message-ID: <65307430906300638m3833c1f0p89a66b030ed74e5a@mail.gmail.com>
To: "Kruessel, Steffen" <Steffen.Kruessel@fokus.fraunhofer.de>
Cc: Marcin Hanclik <Marcin.Hanclik@access-company.com>, Cameron McCormack <cam@mcc.id.au>, WebApps WG <public-webapps@w3.org>
2009/6/30 Kruessel, Steffen <Steffen.Kruessel@fokus.fraunhofer.de>:
> 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]?!

[Callback], despite the names, does not mean that the interface will
be called back by a method accepting it (although that was the initial
use case). It barely means that you can convert an Object (in the
ECMAScript sense) to an object in the WebIDL sense, of that interface.

Without [Callback], passing something to getCurrentPosition() that is
not an host object of the right type causes TypeErrors, following
section 4.1.16. With [Callback] on the PositionOptions interface,
everything is first converted to an object and then to an object
implementing PositionOptions (with undefined attributes, if needed).

Moreover, because your interface is not a "single-operation interface"
(it has attributes and no operations), it does not matter if you
choose FunctionOnly or PropertyOnly.

This is explained in
<http://dev.w3.org/2006/webapi/WebIDL/#native-objects>, but I agree
that some clarification (and maybe a better name than [Callback])
would be better.

> Thank you both in advance
> Steffen
>
> -----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.
>
> Thanks.
>
> Kind regards,
> Marcin
>
> 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});
>
> Right.
>
>> 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
> http://dev.w3.org/2006/webapi/WebIDL/#native-objects.
>
> 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);
>  };
>
>  [Callback]
>  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
>
> --
> 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
>
> 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.
>

Giovanni
Received on Tuesday, 30 June 2009 13:52:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT