- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Sun, 22 Nov 2009 23:40:19 +0100
- To: Aaron Boodman <aa@google.com>, Jonas Sicking <jonas@sicking.cc>
- CC: Robin Berjon <robin@berjon.com>, Adam Barth <w3c@adambarth.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-webapps WG <public-webapps@w3.org>
+1 to this idea The issue is that DAP tries to handle CRUD for multiple types of data. If we want to consider <input type="file"/> for reading files, then we may think of something like the following potential API design pattern: a) <output type="file"/> to possibly trigger File Save As dialog (if it is not only to be programmatic) that would also communicate via URN with JS b) for other types of data we could have <input type="contact" />, <input type="event" /> etc, plus <output type="XXX"/> for those types. The <output>'s would be handled by platform specific UIs, similarly to <input type="file"/> handled by File Open Dialog. BTW: File Open Dialog (actually any similar Dialog) may be regarded as the prompt (oneshot etc) in the policy-based API. This aspect is usually left to implementations. In case of file API the issue is about abstraction of the path with URN. So the path could be available in the policy-based approach, whereas only URN would be available in the policy-less design. If the File API changes "urn" attribute to "url", we could handle both already now. Thanks, Marcin ________________________________________ From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Aaron Boodman [aa@google.com] Sent: Saturday, November 21, 2009 9:31 AM To: Jonas Sicking Cc: Robin Berjon; Adam Barth; public-device-apis@w3.org; public-webapps WG Subject: Re: File writing ponderings (was: Re: Security evaluation of an example DAP policy) On Sat, Nov 21, 2009 at 12:26 AM, Jonas Sicking <jonas@sicking.cc> wrote: > Hmm.. This is a very interesting idea. Definitely worth exploring more. > > What I had in mind was basically something like this: > > 1. An API for creating File objects by concatinating strings, Blobs, > ByteArrays (or whatever they'll be called, see Maciejs proposals to > public-webapps and public-script-coord). A mimetype and a default name > (possibly without extension) would also be assigned to the File in > some fashion. > 2. A API that given a File object brings up the normal "Safe File As" dialog. FWIW, this is what I had in mind, too, back when I used to think about such things. - a ________________________________________ 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 Sunday, 22 November 2009 22:41:16 UTC