RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
What about [ESNativeObject]?
Regarding the whole use case (PositionOptions and its usage in Geo spec,
similar use cases in many BONDI modules) that ignited this mail thread, in
BONDI we consider the proposal of [Enumerable] extended attribute for
interfaces (suggested off-line by Cameron) and [Optional] for attributes. In
short we talk about the case that would resemble passing arguments by value,
that would allow incomplete specification of the object properties - both as
input/argument/value and as output/object and that is about property
enumeration (i.e. about removal of {DontEnum} that is a standard now for Web
IDL interface properties).
There will be another email about that posted soon.
BTW:
Property enumeration seems to be a topic also in this mail thread:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1371.html
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.hanc...@access-company.com
-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Wednesday, July 01, 2009 6:11 AM
To: Cameron McCormack
Cc: Giovanni Campagna; Kruessel, Steffen; Marcin Hanclik; WebApps WG;
i...@hixie.ch
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
On Jun 30, 2009, at 8:12 PM, Cameron McCormack wrote:
Hi Steffen, Giovanni.
Giovanni Campagna:
[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.
I agree with everything Giovanni said.
Regarding the name of the extended attribute: it used to be called
[NativeObject], but there were restrictions on it so that it could
only
be used on interfaces with operations (and not attributes). Ian then
requested it be renamed to [Callback], since that was more
descriptive.
Since that restriction has now been lifted, and [Callback] interfaces
can have attributes, I agree that [Callback] isn't the most obvious
name
any more.
Anybody object to renaming it back to [NativeObject] then (or can
suggest a better name)?
The name NativeObject seems nondescriptive and could easily be taken
as the opposite of what it means. For example, in the browser context,
code written in C++ is often called native but code written in
JavaScript typically is not. But NativeObject would be applied to
interfaces that are expected to be implemented in JavaScript, perhaps
even just by specifying a function directly.
I'm not sure if there is a better word than Callback to connote an
interface that is expected to be implemented by clients of the API
rather than implementation of the API. Maybe ClientInterface or
ClientObject.
Regards,
Maciej
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.
Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
On Jun 30, 2009, at 11:29 PM, Marcin Hanclik wrote: What about [ESNativeObject]? I don't think the property should be ES-specific. It would probably have effects for other language bindings too. I'm also not sure this clarifies the use of Native. Regards, Maciej
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
If the extended attribute should not be ECMAScript, the description at http://dev.w3.org/2006/webapi/WebIDL/#Callback must also be revised due to the strong ES-reference. What about [ValueTypeInterface]? Regards, Steffen -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Wednesday, July 01, 2009 9:15 AM To: Marcin Hanclik Cc: Cameron McCormack; Giovanni Campagna; Kruessel, Steffen; WebApps WG; i...@hixie.ch Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject On Jun 30, 2009, at 11:29 PM, Marcin Hanclik wrote: What about [ESNativeObject]? I don't think the property should be ES-specific. It would probably have effects for other language bindings too. I'm also not sure this clarifies the use of Native. Regards, Maciej
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
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
Steffen
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@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:60});
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
Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
2009/6/30 Kruessel, Steffen steffen.krues...@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-requ...@w3.org [mailto:public-webapps-requ...@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.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@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:60});
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
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Giovanni,
Thank you very much for the explanation. I think I do understand now, but I
also think the description as well as the name may be adjusted to something
more meaningful.
Just one final question. If I define a valuetype of a specified interface,
which is then again used as a parameter in a function, I must also extend the
interface by the [Callback] attribute, don't I?
Example:
typedef sequenceMyInterface MyInterfaceArray;
// Is [Callback] needed here?
[Callback] interface MyInterface {
attribute long id;
};
void myFunction(in MyInterface param);
Thanks
Steffen
-Original Message-
From: Giovanni Campagna [mailto:scampa.giova...@gmail.com]
Sent: Tuesday, June 30, 2009 3:38 PM
To: Kruessel, Steffen
Cc: Marcin Hanclik; Cameron McCormack; WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
2009/6/30 Kruessel, Steffen steffen.krues...@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-requ...@w3.org [mailto:public-webapps-requ...@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.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@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
Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Steffen, Giovanni. Giovanni Campagna: [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. I agree with everything Giovanni said. Regarding the name of the extended attribute: it used to be called [NativeObject], but there were restrictions on it so that it could only be used on interfaces with operations (and not attributes). Ian then requested it be renamed to [Callback], since that was more descriptive. Since that restriction has now been lifted, and [Callback] interfaces can have attributes, I agree that [Callback] isn’t the most obvious name any more. Anybody object to renaming it back to [NativeObject] then (or can suggest a better name)? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
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.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@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:60});
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.
[WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
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:60});
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?
b)
Shouldn't we have the PositionOptions specified as follows?
[NoInterfaceObject]
[Callback=PropertyOnly]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Thanks.
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.hanc...@access-company.com
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.
