RE: Transferring File* to WebApps - redux

Mike,

 

To be clear - I'm not saying that the current File* APIs are poorly
designed or that they won't be useful. As I have read through them I
agree there is a lot of the functionality that we are looking for in
them and we appreciate the effort it took to create them, even though
they are different from the BONDI API (there are many good ways to
design such things). Extending them will be one option if we can't
resolve the gaps in the APIs directly.

 

But if we can count on a couple of key things then in the interest of
having a single API for developers to use, I would agree we should focus
on these APIs and see how far they can take us:

 

1)  An app can use resolveLocalFilesystemURI directly to resolve a
generic filesystem URI, e.g. "documents", "pictures", "videos", "music"
(we can create a normative set of these), or some other URI that is
known to be supported by the device (which is itself known for example
through the System Info API), e.g. file://home/user
<file:///\\home\user> . Alternatively we can extend the LocalFilesystem
interface with a getRootLocations method ala the BONDI filesystem API.

2)  Access to resolveLocalFilesystemURI can be defined in policy (the
resolve method can have an assigned feature URI used in widget config
and policy documents), thus the user does not have to be prompted (if
the app is trusted) or the <input> element used.

 

Note that the alternatives requestPersistentFilesystem and
requestTemporaryFilesystem are quite useful also, and may support the
majority of use cases anyway.

 

Thanks, 

Bryan Sullivan | AT&T

 

From: Mike Clement [mailto:mikec@google.com] 
Sent: Tuesday, June 15, 2010 4:40 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: arun@mozilla.com; Robin Berjon; public-device-apis@w3.org; Ian
Fette; Web Applications Working Group WG
Subject: Re: Transferring File* to WebApps - redux

 

As I understand it, #5 (programmatic access to files without user
interaction) is indeed supported via the getFile method.  But again,
this is only within the sandboxed filesystem, not for an arbitrary file
on the device.

 

As for #6, I can't speak to the "policy-framework approach", but I do
know that the security provisions for manipulating files with regards to
JavaScript will be the usual same-origin policy.

 

--mike

 

 

On Tue, Jun 15, 2010 at 3:55 PM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@att.com> wrote:

Actually I think "sandboxing" an app into a certain area of the
filesystem, especially for less-trusted apps, is a useful model. But I
don't think the current File* APIs will support the items 5-6 that I
mention below.

5) do the above programmatically in Javascript (not dependent just upon
user selection of an input element and interaction with a file selector)

6) provide security for this using the policy-framework approach as
being defined for DAP APIs

 

In BONDI, it's possible to define the sandbox as policy and avoid the
user needing to select it. For example it's possible to restrict an
application to:

*         a "temp" filesystem location (whatever that maps to on the
current device)

*         other "well-known" filesystem locations

*         browser-internal storage (e.g. localstorage)

 

Thanks, 

Bryan Sullivan | AT&T

 

From: Mike Clement [mailto:mikec@google.com] 
Sent: Tuesday, June 15, 2010 3:42 PM


To: SULLIVAN, BRYAN L (ATTCINW)

Cc: arun@mozilla.com; Robin Berjon; public-device-apis@w3.org; Ian
Fette; Web Applications Working Group WG


Subject: Re: Transferring File* to WebApps - redux

 

Hi,

 

Am I correct in thinking that what you find too restrictive is that the
FileSystem API only allows programmatic access to a sandboxed portion of
the device's filesystem instead of the entire filesystem?  Otherwise, I
believe that the File APIs as a whole will allow most of the other
operations you mention.

 

--mike

On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@att.com> wrote:

Arun,

I am not meaning to be unfair, perhaps the message is not coming through
clearly enough.

There are specific technical requirements that we need these APIs to
fulfill, that I indicated to Thomas in another email:
1) access filesystems on the host device
2) traverse directories
3) read files as they exist on the filesystem (not just a local

representation in memory, as currently defined in the File API to my
understanding), in bytes and lines

4) write files (similar requirement to write directly to the

filesystem), in bytes and lines, with overwrite and append options

5) do the above programmatically in Javascript (not dependent just upon

user selection of an input element and interaction with a file selector)

6) provide security for this using the policy-framework approach as

being defined for DAP APIs

Apart from the details of (1-4) above, which will help ensure are
addressed in the current File* APIs (no matter where they are
finished),I think it's (5-6) where the real differences are. If we need
another API in DAP to address them, then AT&T will help ensure it gets
done separately from the current File* APIs.

The question of where you are represented and your ability to
participate cuts both ways - the same is true for us. I think if the
browser vendors want their products really to be seen as compatible with
the Web application space (as compared to just dynamic Web pages), they
will support the work in DAP as its there that non-obtrusive and
inherently secure models for Web application access to device resources
will be defined as APIs.


Thanks,
Bryan Sullivan | AT&T


-----Original Message-----
From: Arun Ranganathan [mailto:arun@mozilla.com]

Sent: Tuesday, June 15, 2010 2:53 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Robin Berjon; public-device-apis@w3.org; Ian Fette; Web Applications
Working Group WG
Subject: Re: Transferring File* to WebApps - redux

On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
> Arun,
>
> The basic concern I have is with the notion of "browsers" as the only
> Web context and use-case that matters. The browser-based model for API
> integration view (as I understand your position) is that the user must
> be actively involved in every significant action, and choose
explicitly
> the actions that enable integration with browser-external resources
> (including local and remote). Step back and you will see the
> inconsistency in that (what would Ajax be if the user had to approved
> every HTTP API request via an<input>  element?).
>

In the case of the File API, I'm merely stating that the capability
should be an evolution on top of what web pages already do with respect
to the input element, and not introduce a new unbounded API space which
doesn't consider user involvement, or reconsiders it with other consent
models.  Equating ajax with this in general isn't relevant to the
argument.

If you have no substantial technical differences with FileReader,
FileWriter, and the FileSystem API, why are you blocking them from
moving?  What additional oversight does the DAP WG provide, that the
WebApps WG does NOT provide?  The WebApps WG has MORE browser vendors
than the DAP WG, allowing review that's pertinent to the technology we
are building.  Below, you say:
> Webapps are much more than just dynamic Web pages. They are
> applications, and with HTML5 will have the ability to rival desktop
> applications, as is clearly the vision of many in the industry. It
might
> even enable a return to a thin client world (e.g. browser as OS) in
> which most significant resources are cloud-based. I see the logic and
> value in that, but it's not the only valid (and valuable) model.
>
> W3C focuses on the Web, and the Web is bigger than the browser
use-case.
> HTML5 and the APIs that attach HTML-based applications to the world
can
> actually be the application platform for the next era of the Web, but
> only if we do not limit the options to the user-centric/control
> paradigms of the past.
>

But, by charter, the DAP WG allows you to address those very use cases!

If the FileWriter, FileSystem, and FileReader specifications do NOT
address the vision you articulate above, why not create a specification
relevant to your use case?  Naturally, browser vendors see value in
technology that serves the cause of dynamic web pages.  Why are you
disallowing maximum browser vendor review by prohibiting a sensible
move?  Even within the DAP WG, feedback isn't as forthcoming on these
specifications as it is in the WebApps WG.

Please reconsider your stance here.  You are not providing technical
feedback on the specifications in question, nor illustrating why they
don't address your use cases.  But, you are blocking them from moving to

a place where there *is* healthy technical feedback, worrying that those

who *are* providing technical feedback will be poor custodians of a
technology they are enthusiastic about building into their products.
This is unfair.

-- A*