[FileReader API, ProgressEvents] Design patterns, FileWriter API

2009-11-17 Thread Marcin Hanclik
Hi, This is a set of architectural comments to the FileReader API, ProgressEvents and the design patterns for DAP. For DAP in [1] I propose the following consistency requirement (still [1] is a very early draft with bugs): All APIs MUST follow the same convention when handling callback

Re: CORS and HTTP error responses

2009-11-17 Thread Anne van Kesteren
On Tue, 17 Nov 2009 01:45:53 +0100, Robert O'Callahan rob...@ocallahan.org wrote: This suggests that the client should expect --- and the server should send --- CORS headers such as Access-Control-Allow-Origin:* in HTTP error responses for public resources. Does that make sense? The spec seems

[widgets] Interface published

2009-11-17 Thread Marcos Caceres
Hi all, Widget interface spec ready for publication (Last Call) [1]. Will be out sometime today (if not already published). And test suite files are now online [2]. Enjoy in moderation! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/ [2]

[widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009

2009-11-17 Thread Arthur Barstow
/test-suite/ Note this spec was formally published as the Widgets APIs and Events spec. If you have any comments re this LCWD: http://www.w3.org/TR/2009/WD-widgets-apis-20091117/ Please send them to public-webapps@w3.org by 8 December at the latest. -Art Barstow

Re: [widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009

2009-11-17 Thread Dominique Hazael-Massieux
Le mardi 17 novembre 2009 à 12:01 -0500, Arthur Barstow a écrit : And test suite files are now online [2]. [[ ++ MWTS WG ]] [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ To be fair, that work only represents Marcos’s efforts so far — I did contribute some test cases, but they

[Widgets] LCWD#3 comments (1)

2009-11-17 Thread Marcin Hanclik
Hi, A couple of comments to the latest PC. 7.4 Media type attribute Media type attribute defines the grammar and refers to RFC2045/6. What about referring to RFC4288 that includes the grammar required for MIME registration [1]? (I have no strong opinion about this point, though.) Numeric

Re: Proposal for sending multiple files via XMLHttpRequest.send()

2009-11-17 Thread Darin Fisher
On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has

Re: Proposal for sending multiple files via XMLHttpRequest.send()

2009-11-17 Thread Maciej Stachowiak
On Nov 17, 2009, at 10:32 AM, Darin Fisher wrote: On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is

Re: comments from Osmosoft on the File API

2009-11-17 Thread Arun Ranganathan
Greetings Paul :) At Osmosoft, we took some time to collectively read the File API Editor's Working Draft 28 October 2009: Thank you very much for taking the time, and sending your review comments. My responses below: Overall we welcome the formalization of access to local files,

Re: more flexible ABNF for STS?

2009-11-17 Thread Julian Reschke
=JeffH wrote: In talking with a couple folks in the past few days, it seems that there already is some thinking about adding some additional directives (aka header field value tokens) to the STS header field. One such idea is an EVonly flag with nominal semantics of accept only an EV cert.

Re: [FileAPI] File.mediaType

2009-11-17 Thread Arun Ranganathan
Marcin Hanclik wrote: What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ? Does it mean that the UAs should always sniff to ensure that the @type is correct? Should we apply the procedure similar to the one from PC

Re: [widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009

2009-11-17 Thread Marcos Caceres
On Tue, Nov 17, 2009 at 6:14 PM, Dominique Hazael-Massieux d...@w3.org wrote: Le mardi 17 novembre 2009 à 12:01 -0500, Arthur Barstow a écrit : And test suite files are now online [2]. [[ ++ MWTS WG ]] [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ To be fair, that work only

[FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft

2009-11-17 Thread Arun Ranganathan
Julian Reschke wrote: Arun Ranganathan wrote: The latest revision of the FileAPI editor's draft is available here: http://dev.w3.org/2006/webapi/FileAPI/ ... 4. A suggestion to *not* have a separate scheme (filedata:) in lieu of urn:uuid:uuid[2] has been the basis of a rewrite of that

Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API

2009-11-17 Thread Arun Ranganathan
Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to

Blob as URN was Re: [FileAPI] Latest Revision of Editor's Draft

2009-11-17 Thread Arun Ranganathan
Eric, I recall you saying at TPAC that you wanted to keep the Blob interface as small as possible, since it seemed likely to get used in a lot of places. I think that's an excellent goal, but of course, having said that, I am immediately going to suggest that you add something to it.

Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft

2009-11-17 Thread Julian Reschke
Arun Ranganathan wrote: Is there a particular reason why a specific URI scheme needs to be called out at all? (there are other schemes that may be more flexible, for instance because they allow using a UUID/String pair for identification). This is a useful question to answer :) I assume

Let's turn WebDatabase into a WG Note

2009-11-17 Thread Nikunj R. Mehta
Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/JavaScript Call

Re: Let's turn WebDatabase into a WG Note

2009-11-17 Thread Maciej Stachowiak
On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2)

Re: Let's turn WebDatabase into a WG Note

2009-11-17 Thread Nikunj R. Mehta
On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we

Re: CORS and HTTP error responses

2009-11-17 Thread Jeff Walden
On 11/17/2009 02:42 AM, Robert O'Callahan wrote: It might be worth explicitly mentioning that CORS headers can (and sometimes should) be included in error responses, perhaps with an example of when that would make sense. Maybe I'm over-paranoid but it just struck me (and Jeff Walden) as

Re: Let's turn WebDatabase into a WG Note

2009-11-17 Thread Maciej Stachowiak
On Nov 17, 2009, at 10:26 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away

Re: Let's turn WebDatabase into a WG Note

2009-11-17 Thread Nikunj R. Mehta
On Nov 17, 2009, at 10:58 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 10:26 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1]