- From: Deepanshu gautam <deepanshu.gautam@huawei.com>
- Date: Fri, 18 Nov 2011 08:53:09 +0000
- To: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>, Robin Berjon <robin@berjon.com>
- Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, "public-device-status@w3.org" <public-device-status@w3.org>
Thanks Jose It would be fine to me (any sort of API. But, since it is related with Vibration I prefer to have it is Vibration API).........As a developer i just don't like relying on UA for this. Regards Deepanshu Gautam Service Standards, Huawei Software T: +86 25 5260008 M: +86 135 85147627 > -----Original Message----- > From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es] > Sent: Wednesday, November 16, 2011 6:10 PM > To: Robin Berjon; Deepanshu gautam > Cc: public-device-apis@w3.org public-device-apis@w3.org; public-device- > status@w3.org > Subject: Re: [vibration] Preliminary thoughts on the vibrator spec > > Maybe if we had a Settings or SysInfo API, the App could detect whether > vibration is on and if not make a request to change that setting to > 'vibratorOn'. Also another possibility would be to do it through an > intent > > Thanks, best > > El 16/11/11 10:55, "Robin Berjon" <robin@berjon.com> escribió: > > >[Do we really need to CC public-device-status? This work is normally > part > >of public-device-apis and not the TF.] > > > >On Nov 16, 2011, at 10:45 , Deepanshu gautam wrote: > >> [DG] I don't quite understand "fingerprinting surface" in this > context > >>but I guess you are referring to "added authorization" which may be a > >>concern for user privacy, correct me if I'm wrong? If I'm right then > I > >>don't understand how it will increase "needed authorization" > >>specifically when user may/must have been authorized by so many other > >>existing ways before even start using the page/application in > question > >>here. Vibration is just a part of the page/application which user > must > >>be authorized/authenticated to use/consume. > > > >Fingerprinting is the practice of identifying a user without requiring > >cookies or other such identifier storage simply by looking at the > >properties publicly exposed by her user agent. A good demo is > >http://panopticlick.eff.org/. > > > >In general we try to avoid fingerprinting because it is a major > privacy > >concern. I'm not convinced that fingerprinting is an issue in this > >specific case, however. > > > >> [DG] I'm sure there are reason for volume control to work this way. > But > >>here, if vibrator is OFF (natively) user may never know (until > notified) > >>that the page/application supports vibrations (this will degrade user > >>experience). And, if Vibration API can handle it without depending on > >>the OS, then why shouldn't it?? This is the model users already > >>understand, so I think we should reuse it. > >> [DG] Do you think user will not understand "Switch on Vibrator?, > allow, > >>not-allow, allow-now, allow-forever"? > > > >I understand your use case but I don't see why it would have to be > >exposed to the web application. The user agent can, of its own accord, > >notice that a page is trying to use vibration (or sound, or whatever > >else) while it is turned off, and notify the user of the issue. UAs > can > >get this right across the board whereas exposing it to pages means > that > >poorly written apps that could use this functionality will forget to > do > >so and leave the user in the cold, and poorly written apps that > shouldn't > >use this functionality will use it and annoy users. > > > >> [DG] PS: Further, I can come up with many usecases where it will be > >>very beneficial for a web app to know if the device is muted, but > that > >>not something we should put up here :-) > > > >If you have use cases, please be sure to send them (in a separate > thread) > >as that topic is a deliverable of this group. > > > >-- > >Robin Berjon - http://berjon.com/ - @robinberjon > > > > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra política de envío y recepción de correo electrónico > en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send > and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Received on Friday, 18 November 2011 08:55:57 UTC