W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

RE: File writing ponderings (was: Re: Security evaluation of an example DAP policy)

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>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C289432A275@OBEEX01.obe.access-company.com>
+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.

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.

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


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:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC