- From: Tran, Dzung D <dzung.d.tran@intel.com>
- Date: Wed, 2 Dec 2009 08:13:43 -0800
- To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Totally agree here. -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of SULLIVAN, BRYAN L (ATTCINW) Sent: Wednesday, December 02, 2009 08:05 AM To: public-device-apis@w3.org Subject: <input type=photo> etc as Capture API Re the proposal to use something along the lines of <input type=photo> to invoke a capture function, that is not an API, but a "user input selection method". An API is a method via which an application invokes a function. There should be no inherent reason that the user must be involved in the invocation of that function (or that there is even a user present). There may be security-related UI considerations that mean that <input type=photo> is a usable approach to getting input to the application, or other security-related UI functions invoked by the web runtime e.g. per a policy framework, but those should not be the only or mandated approaches. We need the ability of applications to be able to interact with device functions without explicit use-by-use involvement of the user. Mandating user explicit user control of each API invocation will result in a unusable user experience, and completely misses the point of defining an API. The BONDI Camera API provides a good model for how this should work. If W3C chooses to define only something along the lines of a <input type=photo> method, then I believe the market will quickly speak to the sufficiency of that approach, and other API designs such as the BONDI Camera API will be more successful. Best regards, Bryan Sullivan | AT&T
Received on Wednesday, 2 December 2009 16:14:22 UTC