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*
>
>