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*
