RE: [vibration] Preliminary thoughts on the vibrator spec

Without being more annoying I would like to stop pursuing my proposal now. If I'm the only one then *probably* I'm wrong.

Regards

PS: However I can't stop my fingers to provide some last inline comments below.

Deepanshu Gautam
Service Standards, Huawei Software
T: +86 25 5260008 M: +86 135 85147627


> -----Original Message-----
> From: Josh Soref [mailto:jsoref@rim.com]
> Sent: Thursday, November 24, 2011 1:21 AM
> To: Deepanshu gautam; Anssi Kostiainen
> Cc: Robin Berjon; public-device-apis@w3.org public-device-apis@w3.org
> Subject: RE: [vibration] Preliminary thoughts on the vibrator spec
> 
> Anssi wrote:
> > Ok, but I don't see a use case for such a method either.
> 
> DG wrote:
> > I disagree :-)
> 
> This isn't how you get things added in our Work Mode.
[DG] I agree and I didn't mean that too. 
> 
> DG wrote:
> > It is not about hard of easy, it is about making this API more
> complete
> > for our developers.
> 
> Our design premise is that we make the simplest API possible to enable
> a basic UC.
> 
> Adding extra knobs is not something we do. Especially things which the
> UA needs to be able to manage on its own.
[DG] OK I'll throw my newly bought pricy Smartphone bcz it cannot detect apps accessing my Vibrator and notify me to switch it ON. And, it will be fine for me to have my consumers play a game (supporting vibrations), developed by me, without vibrations just bcz UA didn't do what it should have.
> 
> And if there's a chance that the UA can't answer the question, then we
> really don't want to do it. It's possible a UA doesn't/can't know if
> vibration is enabled/disabled, and we definitely don't want to create
> events to tell the app "vibration is now available", "vibration is no
> longer available".
[DG] Okay understood...
> 
> 
> DG wrote:
> > I think I have said what I could already to prove my point. It is not
> > like I want this to be handled by App solely (it is not possible
> actually). I
> > just want to make our developer (those who really want to) write good
> quality
> > application enhancing user experience and try to do it as much as
> they can
> > from their part and not relying on UA. I can abandon an app and
> choose a
> > similar from another developer but it is difficult for me to change
> my UA.
> 
> Unfortunately this isn't always the case. Users are often stuck with
> bad apps. Leaving some control at the UA to enable users to live with
> bad apps is important.
[DG] My proposal in no way suggesting to take any control from UA. It is about giving a added functionality to apps which off course was not intended to work without user consent or without UA intervention.
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-
> public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.

Received on Thursday, 24 November 2011 09:04:07 UTC