- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Wed, 2 Dec 2009 17:20:10 +0100
- To: "Tran, Dzung D" <dzung.d.tran@intel.com>, "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
+1 The same principles (API design pattern?) should govern all APIs. As discussed in BONDI, #dap and on DAP ML earlier, it could be subject to policy (defined by any stakeholder [user in some rare cases?] or hard-coded in the UA/WUA) decision which way is enabled and would work. In some unprotected environments it may be required to mandate user consent above all. I believe it is feasible to merge both/all approaches to satisfy all points of view. 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.hanclik@access-company.com -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Tran, Dzung D Sent: Wednesday, December 02, 2009 5:14 PM To: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org Subject: RE: <input type=photo> etc as Capture API 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 ________________________________________ 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.
Received on Wednesday, 2 December 2009 16:21:00 UTC