RE: <input type=photo> etc as Capture API

+1 to both points.
I assume also that the DAP JS APIs should/could be designed in the way to accommodate markup approach (with specific way of realizing the user's consent) to satisfy also the browser perspective.
If some 70% of the JS APIs would be the same for the markup and programmatic approach, then we could elaborate some generic pattern (the starting point for detailed discussions) on how e.g. captureImage() maps to <input type=file accept=image/jpeg>.
Whereas captureImage() is already proposed and shall work in the policy-based environments, it is at least interesting to know the mapping to <input>.
It is about triggering, callbacks vs. events, user's consent etc.

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 SULLIVAN, BRYAN L (ATTCINW)
Sent: Wednesday, December 02, 2009 5:31 PM
To: JOSE MANUEL CANTERA FONSECA; public-device-apis@w3.org
Subject: RE: <input type=photo> etc as Capture API

Jose,
I agree. The markup-based approach is certainly valuable as well. What I think we need from DAP though is a Javascript-callable function, which is a programmatic approach.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
Sent: Wednesday, December 02, 2009 8:28 AM
To: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org
Subject: RE: <input type=photo> etc as Capture API

API definitions are not incompatible with mark-up abstractions that allow to achieve the same functionality.

In HTML you have mark-up and you can achieve the same functionality using the DOM. Depending on the dynamicity of your app you use one or the other

I think DAP is chaired to define APIs and the HTML5 group to define mark-up abstractions ...

Best R.

-----Mensaje original-----
De: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] En nombre de SULLIVAN, BRYAN L (ATTCINW)
Enviado el: miércoles, 02 de diciembre de 2009 17:05
Para: public-device-apis@w3.org
Asunto: <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:39:32 UTC