W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: Bluetooth / NFC APIs

From: Max Froumentin <maxfro@opera.com>
Date: Wed, 03 Mar 2010 11:34:30 +0100
Message-ID: <4B8E3B36.2000301@opera.com>
To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, Max Froumentin <maxfro@opera.com>
CC: Nikolai Onken <nikolai@uxebu.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Claes,

On 02/03/2010 16:32, Nilsson, Claes1 wrote:
> Hi again,
>
> The straightforward solution would of course be to specify an
> additional attribute in the "options" interface that states which
> attribute in each property's interface the threshold attributes
> operate on. This would mean that we also have to define a list of
> enumerated constants for all attributes that the threshold attributes
> can operate on for all defined properties.
>
> This is not very flexible and extensions according to section 5 is a
> problem. However, you have already indicated enumerated constants as
> an issue with extensions.
>
> Any better idea?

No, I'm afraid not. Although we don't have to find a constant for each 
attribute, only the numeric ones. E.g. for network we could just have 
something like THRESHOLD_UPLOAD, THRESHOLD_DOWNLOAD, THRESHOLD_SIGNAL.
Still not great, so I won't edit it in but leave it as an open issue in 
the spec, hoping for a wider audience to express its views.

Max.
Received on Wednesday, 3 March 2010 10:35:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT