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 diff
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
t
Bryan,
On 6/15/10 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
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 DA
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 se
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
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
On Tue, Jun 15, 2010 at 3:11 PM, SULLIVAN, BRYAN L (ATTCINW)
wrote:
> Jonas,
> I guess there might be a parting of the ways here, resulting from
> differing (I guess some would say, incompatible) use cases and the APIs
> that support them.
>
> If the current File APIs in DAP are expected to only s
Jonas,
I guess there might be a parting of the ways here, resulting from
differing (I guess some would say, incompatible) use cases and the APIs
that support them.
If the current File APIs in DAP are expected to only serve the
user-centric browser paradigm then I agree they will not meet the DAP
On Tue, 15 Jun 2010 16:56:31 +0200, Nikunj Mehta
wrote:
Hi all,
I am trying to provide access to constants defined in IndexedDB
interfaces. For example:
interface IDBRequest : EventTarget {
void abort ();
const unsigned short INITIAL = 0;
const unsigned short LOADING = 1;
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
On Tue, 15 Jun 2010, Ashok Malhotra wrote:
>
> Would you agree that this reading between the lines is justified?
Reading between the lines of a technical specification is never justified.
The spec requires exactly what it says, no more, no less.
--
Ian Hickson U+1047E
On Tue, Jun 15, 2010 at 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
>
On Tue, Jun 15, 2010 at 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
>
Hi,
(brief background before jumping out of the blue: I'm working with
Andrei and Jeremy with the IDB implementation..)
I'd like to mention the IDBCursor::continue is also problematic, as
afaict "continue" is a reserved keyword in JS?
oh, "delete" seems to be reserved as well:
https://developer.m
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 acti
On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
We would not be in favor of this transfer. We believe this API needs to
be developed in the DAP group, as our vision for its functionality was
driven by the input from BONDI and in general as a *device* API (as
compared to an abstracted API f
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9888
Nikunj Mehta changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903
Nikunj Mehta changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903
Nikunj Mehta changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Jun 15, 2010 at 9:44 AM, Nikunj Mehta wrote:
> (specifically answering out of context)
>
> On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
>
>> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
>> We couldn't figure out how the old API allowed you to create a range
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/15/2010 12:40 PM, Jeremy Orlow wrote:
> On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking wrote:
>
> On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
> mailto:pablo.cas...@microsoft.com>>
> wrote:
> >>> We developed a similar trick
Hi All,
A few of WebApps' specs, as well as specs from at least one other WG,
have a normative dependency on the Web IDL spec [WebIDL]. Lack of
progress on Web IDL (last published in Sept 2009 and only minor editing
since then) will eventually block the dependent specs from advancing.
Additi
On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking wrote:
> On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
> wrote:
> >>> We developed a similar trick where we can indicate in the IDL that
> different names are used for scripted languages and for compiled languages.
> >
> >>> So all in all I believe
On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
wrote:
>>> We developed a similar trick where we can indicate in the IDL that
>>> different names are used for scripted languages and for compiled languages.
>
>>> So all in all I believe this problem can be overcome. I prefer to focus on
>>> making
This is a Call for Consensus to publish a Candidate Recommendation of
XMLHttpRequest:
http://dev.w3.org/2006/webapi/XMLHttpRequest/
The comment period for the 19 November 2009 LCWD of XHR [LC] ended 16
December 2009 and the disposition of comments for this LCWD is:
http://dev.w3.org/2006
(specifically answering out of context)
On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
> We couldn't figure out how the old API allowed you to create a range
> object without first having a range object.
Hey Jonas,
What
Hi all,
I am trying to provide access to constants defined in IndexedDB interfaces. For
example:
interface IDBRequest : EventTarget {
void abort ();
const unsigned short INITIAL = 0;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned s
Anne van Kesteren wrote:
On Tue, 16 Jun 2009 16:18:25 +0200, Web Applications Working Group Issue
Tracker wrote:
In
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0967.html
Mark Nottingham comments on the asymmetry of exposing the body of the
response but only a tiny subset
On Mon, 14 Jun 2010 20:58:07 +0200, Adam Barth wrote:
On Tue, Feb 16, 2010 at 6:28 AM, Anne van Kesteren
wrote:
On Sun, 06 Dec 2009 17:19:59 +0100, s...@rckc.at wrote:
What about redirects that require different Authentication methods?
How would that work?
Testing shows that Firefox, Ch
On Tue, 15 Jun 2010 13:11:01 +0200, Ashok Malhotra
wrote:
At the TAG f2f meeting last week we discussed the Web Storage
(http://dev.w3.org/html5/webstorage/) draft. As you know, Web Storage
provides storage mechanisms (local storage and session storage) by
origin. This led us to conclude
At the TAG f2f meeting last week we discussed the Web Storage
(http://dev.w3.org/html5/webstorage/) draft. As you know, Web Storage provides
storage mechanisms (local storage and session storage) by origin. This led us
to conclude that it supports the same-origin policy. But section 6.1 conta
On Tue, 16 Jun 2009 16:18:25 +0200, Web Applications Working Group Issue
Tracker wrote:
In
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0967.html
Mark Nottingham comments on the asymmetry of exposing the body of the
response but only a tiny subset of the headers. He argue
On Fri, 07 May 2010 02:30:10 +0200, Anne van Kesteren
wrote:
Here is a brief proposal for how we could simplify the current set of
CORS headers. We can use this thread to evaluate whether it is worth
breaking with what Firefox, Safari, Chrome, and IE are doing now. And
whether all parties
33 matches
Mail list logo
