RE: First stab at File Writer

Hi Robin,

This is a good job. I'm trying to understand the scope of this first
stab wrt to the File System API.

The input model is certainly a good way for a user to e.g. browse a full
directory tree and request that an *existing* file be writable.

In terms of extending that, and according to the programmatic example
provided of requesting to write a 'dahut.txt' file, what is the context
of dahut.txt?

I was thinking of something along the lines of requesting a sandbox in
which to drop this file. Sandboxes do not necessarily relate to
directory trees (at least not to multi-level directory trees) but
instead imply certain permissions for the writing of files to
well-defined areas of a file system.

Such sandboxes could include:

"site://private" - the web apps private storage
"site://public" - the web apps public storage e.g. for inter-service
communcation
"site://temp" - the web apps temporary cache

And could additionally (but with a number of added issues) be extended
to include:

"documents" the documents location, e.g. "My Documents"
"images" the images location, e.g. "My Pictures"
"audios" the audio location, e.g. "My Music"
"videos" the videos location, e.g. "My Videos"
"temp" the global temporary storage



In the case that the input process is used to obtain write permissions
to a specific file (or set of files) this sandbox concept need not
apply. Just save() against the current FileWriter object.


With well-defined sandboxes, I could do the following:

var requestedSandbox = navigator.device.FileWriter.SITE_PRIVATE;
navigator.device.binaryWriter(requestedSandbox, "text/plain", sucCB,
"dahut.txt", { endings: "crlf" }, errCB);


As a user I would then be able to provide permission for this action
against either/both the sandbox and/or the file being requested:

- allow write to this file (for the current site/session only)
AND/OR
- allow write to this sandbox (for the current site/session only)

Going further, some sandboxes may be implicitly writable such as the
site:// temp sandbox.


None of the examples provided in this email are intended to be
prescriptive. This is more about the idea of providing suitable
sandboxes for different usage of the File Writer API in the programmable
context.

I also think this could satisfy a number of use cases from e.g. BONDI.


Kind Regards,

Richard


> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
> Sent: 03 December 2009 17:47
> To: public-device-apis@w3.org
> Subject: First stab at File Writer
> 
> Hi,
> 
> I just checked in a first stab at File Writer. Nothing 
> definitive of course, don't scream if you don't like it (but 
> do provide feedback!).
> 
> You can find it at:
> 
>   http://dev.w3.org/2009/dap/file-system/file-writer.html
> 
> It lists a number of issues which I'm still mulling over. I 
> also need to fill out the section that looks into cut-paste/drag-drop.
> 
> If you don't have time to read all the details, at the very 
> least I'd appreciate feedback and input on the security aspects.
> 
> Before anyone complains that it doesn't address all the file 
> system use cases: that's by design, you also need the file 
> navigation API for that (which will also provide its own ways 
> of creating writers). Of course, you also need the WebApps File API.
> 
> Fire at will!
> 
> --
> Robin Berjon
>   robineko - hired gun, higher standards
>   http://robineko.com/
> 
> 
> 
> 
> 
>

Received on Friday, 4 December 2009 11:59:00 UTC