Abstracting from the technical API details, the only issue and differentiation point between approaches seems to be whether the user's consent is required for the APIs to work.
IMO, the policy model (any) assumes that this is left to the policy.
Then some applications may hard-code the policy (e.g. the browsers could allow only specific policy that would not be updatable).
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 Marcin Hanclik
Sent: Wednesday, December 02, 2009 5:20 PM
To: Tran, Dzung D; SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org
Subject: RE: <input type=photo> etc as Capture API
+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.
________________________________________
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.