Re: RFC: WebApp timing
Zhiheng Wang wrote on 8/12/2009 8:12 PM: >The first cut of the draft is attached below. It's sketchy but should > hold much of our ideas. We are > still actively working on it. Any interest and feedback on the draft are > highly welcome. For navigationType, how would bookmarks, XHR, iframes and "open link in a new window" be reported? For navigationTime (and the other timers), it's a measure of the elapsed time from when the navigation is initiated until when? - Bil
RFC: WebApp timing
Hello,
We recently started a draft to provide timing-related APIs in browsers.
The goal is to add the missingpieces in webapp latency measurements using
Javascript. As a starter, right now we've only include a
minimum set of interfaces we consider necessary, which mainly focuse on the
time and type of the
navigation.
The first cut of the draft is attached below. It's sketchy but should
hold much of our ideas. We are
still actively working on it. Any interest and feedback on the draft are
highly welcome.
cheers,
Zhiheng
Title: Web Timing
Web Timing
Working Draft 12 August 2009
This version:
http://example.com/
Latest version:
http://example.com/
Previous versions:
http://example.com/
Editors:
Zhiheng Wang, Google
Inc., zhihe...@google.com
Copyright 2009, All Rights Reserved
Abstract
This specification defines a set of APIs for web applications to access
timing information.
Status of this document
This is a work in progress and may change without any
notices.
If you wish to make comments regarding this document, please send them to
zhihe...@google.com. All feedback is welcome.
Table of Contents
Introduction
This section is non-normative
User latency is an importing quality benchmark for Web Applications. While
_javascript_-based mechanisms can provide comprehensive instrumentations user
latency measurements within an application, in many cases, they are not able to
provide a complete end-to-end latency picture due to the missing latency pieces
from the user agents. This document introduces a set of timing APIs aiming to
provide the missing pieces.
Conformance requirements
All diagrams, examples, and notes in this specification are non-normative, as
are all sections explicitly marked non-normative. Everything else in this
specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are
to be interpreted as described in RFC2119. For readability, these words do not
appear in all uppercase letters in this specification. [RFC2119]
Requirements phrased in the imperative as part of algorithms (such as "strip
any leading space characters" or "return false and abort these steps") are to be
interpreted with the meaning of the key word ("must", "should", "may", etc) used
in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes,
methods or objects. Such requirements are to be interpreted as requirements on
user agents.
Conformance requirements phrased as algorithms or specific steps may be
implemented in any manner, so long as the end result is equivalent. (In
particular, the algorithms defined in this specification are intended to be easy
to follow, and not intended to be performant.)
Terminology
The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the
more accurate "an object implementing the interface Foo".
The term DOM is used to refer to the API set made available to scripts in Web
applications, and does not necessarily imply the existence of an actual
Document object or of any other Node objects as
defined in the DOM Core specifications. [DOM3CORE]
A DOM attribute is said to be getting when its value is being
retrieved (e.g. by author script), and is said to be setting when a new
value is assigned to it.
The term "_javascript_" is used to refer to ECMA262, rather than the official
term ECMAScript, since the term _javascript_ is more widely known. [ECMA262]
Web Application Timing
Introduction
This section is non-normative
This specification introduces a set of of browser interfaces that provide Web
applications with timing-related information. This specification does not cover
how Web applications leverage these interfaces to collect, store and report the
provided information.
The Timing
interfaceinterface Timing {
const unsigned short NAVIGATION_LINK = 0;
const unsigned short NAVIGATION_REDIRECT_SERVER = 1;
const unsigned short NAVIGATION_REDIRECT_META = 2;
const unsigned short NAVIGATION_REDIRECT_ONLOAD = 3;
const unsigned short NAVIGATION_REDIRECT_JAVASCRIPT = 4;
const unsigned short NAVIGATION_FORWARD_BACK = 5;
const unsigned short NAVIGATION_USER_BROWSER = 6;
const unsigned short NAVIGATION_NEW_WINDOW = 7;
const unsigned short NAVIGATION_RELOAD = 8;
const unsigned short NAVIGATION_OTHER = 15;
readonly attribute unsigned short navigationType;
readonly attribute unsigned long navigationTime;
readonly attribute unsigned long redirectionTime;
readonly attribute unsigned long domainLookupTime;
};
The navigationType
attribute
The navigationType attribute must
return the type of the last navigation,
whose possible values must include:
NAVIGATION_LINK: navigation start
by clic
Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote: Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Thanks Arun! Anne van Kesteren wrote: I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] Yeah. Come to think of it though, it needs to be specified on File rather than FileData. For a data URL you need the media type and that is only available from File (and does not make sense for all of FileData). I agree with this. I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Done. I think this also should only be available on File. This would probably be fine, although for filedata: URLs, we don't *need* a mediaType (we could just define octet stream or something on slice'd FileData objects). I'm ok with moving it, thought. Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Possibly, but I was thinking of having slice throw exception.SLICE_ERR if the range mathematics is wrong. It probably won't need to throw for any other reasons. Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core. Agreed! The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the "//", but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? If you can store and open documents I imagine you can view them inside as well and it would make sense if you could set fragment identifiers of such a resource to scroll within them. SVG couples special semantics to the fragment identifier for image/svg+xml resources. If the user selects an SVG resource an application might want to use such fragment identifiers. Agreed, I'll add this to my ToDos for FileAPI. Yeah, though I'd replace "encoding is in UTF-8" with "encoding is UTF-8". OK I think it should be explicit if we want implementations to use XML/HTML rules to determine the character encoding when the media type of the file matches. OK By the way, you have written "mediatype" rather than "media type" twice. I'll fix this. -- A*
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Wed, Aug 12, 2009 at 4:33 PM, Ian Hickson wrote:
> On Mon, 3 Aug 2009, Aaron Boodman wrote:
>> >
>> > The API was intentionally made more obviously synchronous to avoid
>> > having to make people use callbacks.
>> >
>> > Would making all transactions automatically rollback if not committed
>> > when the event loop spins be an acceptable substitute solution?
>>
>> A few problems with this:
>>
>> - In the case of workers, it could be more common for a single event
>> loop entry to last a very long time. So closing the transaction on event
>> loop exit could effectively mean "never".
>
> I don't think reentrant callbacks really get around that much, though
> maybe they make it a little more obvious.
My point was just that using a closure eliminates the case where a
transaction gets left open because of buggy code. It eliminates the
problem where a transaction should have been closed, but wasn't.
You're right that it does nothing for an infinite loop inside a
transaction. Nothing will save us from that.
>> I also don't see what not having a callback buys. I'm not sure if you
>> noticed, but I was suggesting that the callback be reentrant. So if you
>> do this:
>>
>> var theResult = null;
>> database.syncTransaction(function(tx) {
>> theResult = tx.executeSQL("select * from ...").rows[0].val;
>> });
>> alert(theResult);
>>
>> It will do the right thing. Are you concerned that developers won't
>> realize that the callback is reentrant and will invest more effort
>> writing their code in an asynchronous style?
>
> The only reason for not using callbacks in the sync API was that callbacks
> are harder to work with than the straight-forward imperative style.
>
> I can change the spec to a hybrid style with statements in the imperative
> form but the transactions themselves using closures. Would that be ok?
Yes, that is what I was proposing.
- a
Re: please fix status of File Upload editor's draft
Garrett Smith wrote:
Good to get more notice on the API, but saying things like "Arun is a
great guy" in that same entry indicates impartiality.
He's a reasonably good guy, though :-)
AISB, the "2006" uri returns the latest "editors draft" and the
"Latest public version" at "/TR/file-upload/" has old content.
This spec. has a long history. The CVS repository is misleadingly
named, so it has "FileUpload" in it, which confuses people. And there's
the date issue ("2006"). Both should be fixed, and are on my list of
"ToDos."[1]
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0597.html
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, 3 Aug 2009, Aaron Boodman wrote:
> >
> > The API was intentionally made more obviously synchronous to avoid
> > having to make people use callbacks.
> >
> > Would making all transactions automatically rollback if not committed
> > when the event loop spins be an acceptable substitute solution?
>
> A few problems with this:
>
> - In the case of workers, it could be more common for a single event
> loop entry to last a very long time. So closing the transaction on event
> loop exit could effectively mean "never".
I don't think reentrant callbacks really get around that much, though
maybe they make it a little more obvious.
> - It is likely to lead to difficult to debug issues. In the common path,
> developers will close transactions because they will notice incorrect
> code during development. It is only in the error cases that they will
> forget to close the transactions. So every so often, you'll get errors
> or hung workers (depending on what the behavior is spec'd to be when you
> open a sync transaction while another is open in the same worker), and
> no good way to track down the transaction that was left open. In my
> experience with Gears, to avoid these issues, the very first thing
> developers did was write a wrapper around the Gears API that worked the
> way I'm suggesting.
Fair enough.
> I also don't see what not having a callback buys. I'm not sure if you
> noticed, but I was suggesting that the callback be reentrant. So if you
> do this:
>
> var theResult = null;
> database.syncTransaction(function(tx) {
> theResult = tx.executeSQL("select * from ...").rows[0].val;
> });
> alert(theResult);
>
> It will do the right thing. Are you concerned that developers won't
> realize that the callback is reentrant and will invest more effort
> writing their code in an asynchronous style?
The only reason for not using callbacks in the sync API was that callbacks
are harder to work with than the straight-forward imperative style.
I can change the spec to a hybrid style with statements in the imperative
form but the transactions themselves using closures. Would that be ok?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
ToDos on File API | Re: please fix status of File Upload editor's draft
There are quite a few things I'd like to do still on this draft, leaving aside the question of changing the API, which I'd like to see more discussion on [1]. It's worth documenting these things as "ToDos" so the WG knows I'm working on them: 1. Terser, clearer prose on asynchronous accessor methods, including better description of integration with HTML5 event loops. 2. Response to a number of public-webapps email that I haven't responded to yet. There's quite a bit of feedback left. Of course, more is always welcome :-) 3. Flesh out the processing model for filedata: URLs (e.g. add a 405 Method Not Allowed); right now we use a subset of HTTP response codes. 4. Raising the issue with TAG (or IETF/HTTPbis) about a new scheme (filedata:) It may be wise to simply reuse the urn: scheme with UUIDs [2], but I'll need more investigation about this. Discussion about the proposed URL is likely to be lengthy :-\ 5. Potentially removing getAsBase64 6. Formatting issues, especially changing the name of the CVS rep. It is currently named to be /2006/webapi/FileUpload/publish/ which is really misleading, since people are confusing "upload" with file access. The '2006' and the 'FileUpload' are historical leftovers :-) I hope to make headway on these issues by next week. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html [2] http://www.ietf.org/rfc/rfc4122.txt Dan Connolly wrote: On Wed, 2009-08-12 at 13:55 -0700, Arun Ranganathan wrote: [...] Fixed; I hope the status is clearer now yes; thanks for the quick fix. (you may have to force a reload to see the changes). http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- A*
Re: please fix status of File Upload editor's draft
On Wed, Aug 12, 2009 at 1:55 PM, Arun Ranganathan wrote: > Dan Connolly wrote: >> >> Looks like the word is getting out about this work; >> there's a pretty favorable article on ajaxian. >> http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api >> >> But it's a little confused... >> "The W3C has published a working draft for the File API" >> >> W3C hasn't actually published it just yet. >> >> No wonder they're confused... >> In http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Yeah. Ajaxian should edit that entry to something like: "there is an editors draft in the making" and then presented the goals/objective of the API. Good to get more notice on the API, but saying things like "Arun is a great guy" in that same entry indicates impartiality. >> >> I find >> "This document is a First Public Working Draft. It is not an official >> publication of the W3C." >> >> That's contradictory. Please take out the 1st sentence or something. >> >> It's also labelled "W3C Working Draft 12 August 2009" on the >> title page. >> >> Please delete that subtitle or change it to "editor's draft" >> or some such. See http://www.w3.org/2005/03/28-editor-style >> for some concrete suggestions. >> >> >> > > Fixed; I hope the status is clearer now (you may have to force a reload to > see the changes). > http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html > I mentioned before that "2006" URI has a link to the latest: | Latest public version: |http://www.w3.org/TR/file-upload/ That page has a previous draft (Robin's?) That latest version:- | File Upload | W3C Working Draft 18 October 2006 AISB, the "2006" uri returns the latest "editors draft" and the "Latest public version" at "/TR/file-upload/" has old content. That should be fixed so that the latest version does truly point to the latest version. I do not know the rules for how W3C usually publishes things, but it is confusing to have the "latest" uri having old content and the "2006" uri having the actual up-to-date editors draft. At the very least, the link to the latest version ought to return the latest up-to-date version. Garrett > -- A* > > >
Re: please fix status of File Upload editor's draft
On Wed, 2009-08-12 at 13:55 -0700, Arun Ranganathan wrote: [...] > Fixed; I hope the status is clearer now yes; thanks for the quick fix. > (you may have to force a reload > to see the changes). > http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html > > -- A* -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Re: please fix status of File Upload editor's draft
Dan Connolly wrote: Looks like the word is getting out about this work; there's a pretty favorable article on ajaxian. http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api But it's a little confused... "The W3C has published a working draft for the File API" W3C hasn't actually published it just yet. No wonder they're confused... In http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html I find "This document is a First Public Working Draft. It is not an official publication of the W3C." That's contradictory. Please take out the 1st sentence or something. It's also labelled "W3C Working Draft 12 August 2009" on the title page. Please delete that subtitle or change it to "editor's draft" or some such. See http://www.w3.org/2005/03/28-editor-style for some concrete suggestions. Fixed; I hope the status is clearer now (you may have to force a reload to see the changes). http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- A*
please fix status of File Upload editor's draft
Looks like the word is getting out about this work; there's a pretty favorable article on ajaxian. http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api But it's a little confused... "The W3C has published a working draft for the File API" W3C hasn't actually published it just yet. No wonder they're confused... In http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html I find "This document is a First Public Working Draft. It is not an official publication of the W3C." That's contradictory. Please take out the 1st sentence or something. It's also labelled "W3C Working Draft 12 August 2009" on the title page. Please delete that subtitle or change it to "editor's draft" or some such. See http://www.w3.org/2005/03/28-editor-style for some concrete suggestions. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Re: [File API] events vs callbacks
On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren wrote:
> On Wed, 12 Aug 2009 20:09:20 +0200, Jonas Sicking wrote:
>> On Wednesday, August 12, 2009, Anne van Kesteren
>> wrote:
>>> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking
>>> wrote:
xhr.open("GET", myFile.slice(x, y).fileDataURI);
xhr.send();
>>>
>>> FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually
>>> think that when using the filedata URL scheme some kind of exception
>>> needs to be thrown. Similarly to when you would use mailto or something.
>>
>> Why?
>
> Because we'd need to define how this works and define that non-GET, non-null
> send(), setRequestHeader(), etc. are all not having any effect for filedata
> URLs. That seems silly. It seems way better to admit that XMLHttpRequest
> provides an HTTP API and not a File API, in my opinion.
In order for filedata URLs to be viable in the File API spec in any
form, it needs to be defined to the level of detail that it is useful
for any consumer of URLs. Thus it has to define answers to your
questions above. No changes needed to the XMLHttpRequest spec, or
XMLHttpRequest implementations.
So if we don't want XMLHttpRequest to work with filedata URLs, we
would need to define an explicit exception in the XMLHttpRequest
specification. And implementations would need to add explicit code
that rejects filedata URLs. *That* seems silly IMHO.
/ Jonas
Re: [File API] events vs callbacks
On Wed, 12 Aug 2009 20:09:20 +0200, Jonas Sicking wrote:
> On Wednesday, August 12, 2009, Anne van Kesteren
> wrote:
>> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking
>> wrote:
>>> xhr.open("GET", myFile.slice(x, y).fileDataURI);
>>> xhr.send();
>>
>> FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually
>> think that when using the filedata URL scheme some kind of exception
>> needs to be thrown. Similarly to when you would use mailto or something.
>
> Why?
Because we'd need to define how this works and define that non-GET, non-null
send(), setRequestHeader(), etc. are all not having any effect for filedata
URLs. That seems silly. It seems way better to admit that XMLHttpRequest
provides an HTTP API and not a File API, in my opinion.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: New FileAPI Draft | was Re: FileAPI feedback
On Wed, Aug 12, 2009 at 7:42 AM, Arun Ranganathan wrote: >> What's the use-case for getAsBase64? > > It's generally hard to encode files and to send them to servers. While Data > URLs give developers a convenient way to work with Base64, URL length > limitations across user agents make it pretty tough to use in practice. And > while we do have a getAsBinaryString now, I still think getAsBase64 is > important because of the fact that many server environments provide ways to > work with Base64 strings (e.g. PHP's base64_decode method, which is really > useful along with an XHR that submits Base64 encoded strings, as well as > Perl's decode_base64, etc.). > It's a convenient way to encode file data and servers work with it out of > the box . The drawback is that it increases the data size from the original > file. The fact that servers can work with base64 encoded strings is not a reason for wanting to do so. If you want to send data to the server it seems much more desirable to send the raw data to the server. Unless you are arguing that there are servers out there that can't consume the raw data, but that could consume base64 encoded data? in other words, "because the server could consume it" is not a good reason to send data in a particular format to the server. The reason should be "because there's advantage X with sending in in that format". So far I don't see an advantage "X" with base64. / Jonas
Re: [File API] events vs callbacks
On Wednesday, August 12, 2009, Anne van Kesteren wrote:
> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking wrote:
>> xhr.open("GET", myFile.slice(x, y).fileDataURI);
>> xhr.send();
>
> FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually think
> that when using the filedata URL scheme some kind of exception needs to be
> thrown. Similarly to when you would use mailto or something.
Why?
/ Jonas
Re: Publishing XMLHttpRequest
Anne van Kesteren wrote: > On Wed, 12 Aug 2009 17:17:09 +0200, Stewart Brodie wrote: > > Please could you add an appendix in the latter that summarises what's > > new in the new version? > > Is there anything the Abstract does not cover you would like to see > mentioned? The Abstract is good for an abstract, but I don't think it's got enough detail in it for a list of differences. I'll review the new documents in closer detail when I get a chance and see if I can suggest some words. I'd like to adopt some of the new features into my implementation too, as time permits, probably starting with things like overrideMimeType that are already widely implemented elsewhere. > > I believe it is true to say that a "conforming user agent" as defined by > > XMLHttpRequest-2 cannot also a "conforming user agent" as defined by > > XMLHttpRequest (not least because the introduction of CORS overrides the > > requirement to throw SECURITY_ERR at various points). > > Yeah. I thought of changing the original XMLHttpRequest to match this new > reality, but was not sure whether it is worth it. Probably not. It's kind of weird to be able to modify both versions of the specification at once! > > What is the recommended way for code to discover to which version of the > > specification an implementation conforms? > > I rather not recommend a particular strategy as I'm sure users of the API > are much more skilled in dealing with issues such as this one. OK, thanks. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [File API] feedback on August 1/5 draft
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote: > Latest draft is: > http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Thanks Arun! > Anne van Kesteren wrote: >> I have not received any feedback on my comments as to why getAsDataURL >> is actually needed. I still think it should be dropped. > > The rationale submitted by Jonas seems to be sufficient. [1] Yeah. Come to think of it though, it needs to be specified on File rather than FileData. For a data URL you need the media type and that is only available from File (and does not make sense for all of FileData). >> I think getAsURL() should become an attribute instead. E.g. >> >> readonly attribute DOMString localURL; >> >> Since it is just a reference there is no need this needs to be >> asynchronous and there is also no need for it to be method. > > Done. I think this also should only be available on File. >> The constants of FileError need to be actually placed on the FileError >> object and renumbered as to make sense. They are not DOM exceptions so >> it does not make sense to align with that in any way. > > They are placed on the FileError object now, but have not been > renumbered. Additionally, slice is now spec'd to throw a FileException. > > I'm not tightly wed to keeping the numbers the same as DOMException, but > honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems > desirable. SECURITY_ERR is used by XHR as well, so keeping these > consistent (since File API will probably used in conjunction with XHR) > also seems desirable. I also agree that simply using a meaningful > constant name is also useful, but kept the numbers the same for > consistency. > > Aside from numbering, I don't think there's a big difference between > FileError / FileException and SQLError/SQLException (or MediaError, > etc.). Do you feel very strongly about renumbering? Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core. >> The filedata URI scheme should allow the use of fragment identifiers on >> the resource. Also, I think we should drop the // from the scheme. I do >> not see why that is needed here. > > I've dropped the "//", but haven't spec'd the scheme to allow fragment > identifiers on the resource. Could give me a use case? If you can store and open documents I imagine you can view them inside as well and it would make sense if you could set fragment identifiers of such a resource to scroll within them. SVG couples special semantics to the fragment identifier for image/svg+xml resources. If the user selects an SVG resource an application might want to use such fragment identifiers. >> Last time I also made comments regarding the details of discovering the >> encoding of a file etc. Those still seem to apply. > > Anne, I thought that even my past draft addressed most of them, with one > exception! These comments seem to have been: > > * I assume it is meant that if the encoding parameter is not provided > UTF-8 is used for decoding the file. I think that should be made more > clear. > > --> It is clear, but only iff. implementations cannot determine a > decoding to use. You've said that the "left to implementations" part is > unacceptable, but that actually seems desirable, and they MUST use UTF-8 > if they cannot determine the decoding. Since they must fall back on > UTF-8, is this not sufficient? Yeah, though I'd replace "encoding is in UTF-8" with "encoding is UTF-8". > * However, wouldn't it be better to use e.g. XML rules for XML files > and HTML rules for HTML files? > > --> The File interface has a mediaType attribute. I reasoned that by > determining the mediaType, callers can determine which rules to use, or > at least determine whether they can use the filedata: scheme to surface > the content, etc. Would you like me to make explicit statements about > XML/HTML, or is this sufficient? I think it should be explicit if we want implementations to use XML/HTML rules to determine the character encoding when the media type of the file matches. > * It would also make sense to observe any BOM the file might have and > maybe information provided by the platform? Rules similar to how > responseText for XMLHttpRequest is computed could be used here I think. > > --> I specify that user agents can make a determination, and assumed > this as the case. I can make this more explicit in a subsequent draft, > and look at responseText rules. This is probably the only thing not > fully addressed, unless you have further nits on how I've addressed your > other nits. I'd like it all to be explicit, but if I'm the only one I'm willing to concede on this. By the way, you have written "mediatype" rather than "media type" twice. > [1] > http:
Re: Publishing XMLHttpRequest
On Wed, 12 Aug 2009 17:17:09 +0200, Stewart Brodie wrote: > Please could you add an appendix in the latter that summarises what's > new in the new version? Is there anything the Abstract does not cover you would like to see mentioned? > I believe it is true to say that a "conforming user agent" as defined by > XMLHttpRequest-2 cannot also a "conforming user agent" as defined by > XMLHttpRequest (not least because the introduction of CORS overrides the > requirement to throw SECURITY_ERR at various points). Yeah. I thought of changing the original XMLHttpRequest to match this new reality, but was not sure whether it is worth it. > What is the > recommended way for code to discover to which version of the > specification an implementation conforms? I rather not recommend a particular strategy as I'm sure users of the API are much more skilled in dealing with issues such as this one. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] feedback on August 1/5 draft
Michael Nordman wrote: >The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. This should have been an editor's note, and not a part of the spec. text. The "unique" and "hard to guess" nature of the URL is covered by both lifetime and origin requirements, and I think the "new coinage" requirement was overkill without payoff :-) I've eliminated that requirement, and thus we now have filedata.url which returns a filedata: scheme URL. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- A*
Re: Publishing XMLHttpRequest
Anne van Kesteren wrote: > Given the number of changes it seems best to simply publish another > Working Draft for now of both XMLHttpRequest and XMLHttpRequest Level 2 > and see where that brings us. It would help if we have more > implementations trying to seriously implement it so we could declare the > draft more stable, but it seems we are not quite there yet. > > I'd like to request that we publish these two drafts: > > http://dev.w3.org/2006/webapi/XMLHttpRequest/ > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Please could you add an appendix in the latter that summarises what's new in the new version? I believe it is true to say that a "conforming user agent" as defined by XMLHttpRequest-2 cannot also a "conforming user agent" as defined by XMLHttpRequest (not least because the introduction of CORS overrides the requirement to throw SECURITY_ERR at various points). What is the recommended way for code to discover to which version of the specification an implementation conforms? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [File API] feedback on August 1/5 draft
Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Anne van Kesteren wrote: Thanks for the update to the draft! Below some feedback: In the table of contents the link to the filedata URL scheme is broken. Fixed. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequence FileList; Done I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Done. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. They are placed on the FileError object now, but have not been renumbered. Additionally, slice is now spec'd to throw a FileException. I'm not tightly wed to keeping the numbers the same as DOMException, but honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems desirable. SECURITY_ERR is used by XHR as well, so keeping these consistent (since File API will probably used in conjunction with XHR) also seems desirable. I also agree that simply using a meaningful constant name is also useful, but kept the numbers the same for consistency. Aside from numbering, I don't think there's a big difference between FileError / FileException and SQLError/SQLException (or MediaError, etc.). Do you feel very strongly about renumbering? The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the "//", but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Anne, I thought that even my past draft addressed most of them, with one exception! These comments seem to have been: * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. --> It is clear, but only iff. implementations cannot determine a decoding to use. You've said that the "left to implementations" part is unacceptable, but that actually seems desirable, and they MUST use UTF-8 if they cannot determine the decoding. Since they must fall back on UTF-8, is this not sufficient? * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? --> The File interface has a mediaType attribute. I reasoned that by determining the mediaType, callers can determine which rules to use, or at least determine whether they can use the filedata: scheme to surface the content, etc. Would you like me to make explicit statements about XML/HTML, or is this sufficient? * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. --> I specify that user agents can make a determination, and assumed this as the case. I can make this more explicit in a subsequent draft, and look at responseText rules. This is probably the only thing not fully addressed, unless you have further nits on how I've addressed your other nits. * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the "Platform". --> Done. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0511.html
Re: New FileAPI Draft | was Re: FileAPI feedback
splice should synchronously return a new FileData object. No need for asynchronous callback since no IO occurs. Done, though I used Anne's suggestion to make it an attribute. Whoops, no I didn't mean Anne's suggestion for slice -- I meant it for getAsURL. Also the current draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Re: FileAPI "splice" method
Adam de Boor wrote: this is a minor point, but I'm finding the name of the "splice" method to be odd. To me splice means to join, and "slice" would seem a more appropriate name. The Array object has both splice and slice, and the former is used for removing and inserting data and modifies the array in place, while the latter pulls out a sub-part of the array into a new array. a Agreed -- the method is renamed. "splice" was just a clumsy choice for a name on my part :-) -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
Jonas Sicking wrote: A few comments: Need to specify that all getAsX functions call the callback *asynchronously*. Also need to integrate this with the HTML5 event loop. Done. getAsBinary should be called getAsBinaryString so that once we have a BinaryArray or some such we can add a getAsBinary that truly returns binary data. Done Need to specify the actual encoding for getAsBinary, i.e. that each character holds one byte, valued between 0-255. Done, though this generated an editor's note. Obviously the filedata scheme needs to be defined in greater detail. Done -- comments welcome. What's the use-case for getAsBase64? It's generally hard to encode files and to send them to servers. While Data URLs give developers a convenient way to work with Base64, URL length limitations across user agents make it pretty tough to use in practice. And while we do have a getAsBinaryString now, I still think getAsBase64 is important because of the fact that many server environments provide ways to work with Base64 strings (e.g. PHP's base64_decode method, which is really useful along with an XHR that submits Base64 encoded strings, as well as Perl's decode_base64, etc.). It's a convenient way to encode file data and servers work with it out of the box . The drawback is that it increases the data size from the original file. Do you disagree with why I think it is useful? splice should synchronously return a new FileData object. No need for asynchronous callback since no IO occurs. Done, though I used Anne's suggestion to make it an attribute. getAsBinaryString could take two optional |start| and |length| arguments to avoid having to use splice to read parts of a file. Currently, slice allows us to create new byte-ranged FileData objects. Is that not sufficient? The advantage of using slice, and then calling any accessor you want (including getAsBinaryString) is that you can do much more than with just an arbitrary byte-ranged binary string. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
Gregg Tavares wrote: How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format "filedata: uuid, filename" Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are neede Today, it's possible to use XHR from "privileged web content" in Firefox to access file:// URLs; the drawback is that these don't return HTTP responses, and of course there are security considerations. I'm not sure it is necessary to reuse the XHR primitive for general file access (though I find the idea of not distinguishing remote files from local pretty attractive), but I have defined the filedata: URL scheme to return some HTTP response codes [1], so that it can be used with XHR. What is permitted and what is not is bound to be a controversial discussion :-) -- A* [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Alain Vagner is out of the office.
I will be out of the office starting Fri 08/07/2009 and will not return until Mon 08/17/2009. I will respond to your message when I return.
Re: FileAPI Feedback
Garrett Smith wrote: In glancing at some of the methods in FileAPI, I noticed some coding errors. There definitely were errors; thank you for catching them. First, an overview explanation: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml#dfn-getAsDataURL |... If the call is successful, implementations MUST | call the callback function with a string argument | that is a valid data URL [RFC2397], and with a SUCCESS | error code on the FileError object... What is a SUCCESS error code? It sounds like SUCCESS is a "status" code that would not be an error. I also understood from your prior post that the errorHandler parameter was gone, yet I still see that in the example code below. SUCCESS is in fact a status code, and the rest of the codes correspond to errors. I think calling it an error code is misleading, so I'll endeavor to fix that. In a previous post, I said that the error callback was gone, and that now error handling for the asynchronous data accessors was via the FileError object used on the callback as an argument. The "status code" and a "getData" method could be designed as properties of one object. I'm not sure I understand. Which object do you mean here? |// (GS) What is the second parameter "error"? | function handleURL(fileAsDataURL, error) | This is the FileError object, used as an argument on the callback to report errors. | // (GS) best to keep this on local Variable object, | // not assigning to window.status. Good catch -- thank you :-) -- A*
Re: Alternative File API
Jonas Sicking wrote:
Here is an alternative proposal for an API for reading files:
[Constructor, Implements=EventTarget]
interface FileRequest {
readAsBinaryString(in FileData filedata);
readAsText(in FileData filedata, [Optional] in DOMString);
readAsDataURL(in File file);
abort();
const unsigned short INITIAL = 0;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
readonly attribute DOMString response;
readonly attribute unsigned long status;
attribute Function onloadstart;
attribute Function onprogress;
attribute Function onload;
attribute Function onabort;
attribute Function onerror;
attribute Function onloadend;
};
Additionally, inside DOM Workers we could supply the following interface:
[Constructor]
interface FileRequestSync {
DOMString readAsBinaryString(in FileData filedata);
DOMString readAsText(in FileData filedata, [Optional] in DOMString);
DOMString readAsDataURL(in File file);
};
As stated, I'm not convinced that this is a better solution than what
the spec currently does. The only advantage I can see is that it
supports progress events without requiring the use of XMLHttpRequest,
While the above API does have the advantages that we agree come with a
model that stems from EventTarget and events, I'm concerned that we've
complicated the API for an edge case. I *do* agree that progress events
are desirable, especially given leaky abstractions for file systems
(e.g. the user plugs in a networked drive, which is surfaced from the
input type="file" picker) which could behave slowly. But this seems
like a desirable edge case which we should find another solution for,
and not overhaul the entire API. In fact, progress events for file APIs
seem pretty sugary in general; many of the other platforms I've looked
at for File APIs don't have them. That's not to say that the web
shouldn't have it -- I'm just pointing out that I think most users of
the API will simply call the API to get the file. And, I think that in
the lion's share of use cases, things will behave rapidly enough to not
warrant the use of progress events (except during the networked/plugged
in scenarios). So, I think we could investigate adding progress
feedback without changing the existing model.
Current draft:
myFile.getAsBinaryString(handler);
function handler(data, error) {
doStuffWith(data);
}
Above API:
reader = new FileReader;
reader.readAsBinaryString(myFile);
reader.onload = handler;
function handler(event) {
doStuffWith(event.target.response);
}
We can discuss adding progress feedback to the current draft via another
optional callback that is an argument to the asynchronous data accessor
methods, and we can make arguments on this callback match those in
ProgressEvents [1].
An example might be:
[CallBack=FunctionOnly, NoInterfaceObject] interface ProgressReport {
void handleEvent(in unsigned long loaded, in unsigned long total);
};
which we can specify is optionally used with the asynchronous data
accessors, and which (if provided) implementations will call within the
HTML5 event loop (like progress events, with the same frequency, etc.).
There may be other solutions as well.
The advantage is that we stick with the existing model, which I honestly
believe is simpler. The disadvantage is that we don't use the full
event model here, which is a trade-off (and as has pointed out, there
definitely isn't consensus on this). There's also a general argument
that's been made on the listserv for extensibility, which I'm not sure I
fully understand, since I think that even an event model has similar
problems.
I'm perfectly amenable to changing the existing draft, which has been
updated based on earlier feedback [2], but I'd like to emphasize that my
reluctance to switch to a model such as the one above is honestly for
simplicity's sake. Ideally, authors will be able to access files
intuitively, using the simplest "language of files" (get the file, do
something with it).
I'd really like to hear from others, particularly implementors who have
been silent till now :-)
-- A*
[1] http://www.w3.org/TR/progress-events/
[2] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Publishing XMLHttpRequest
The last XMLHttpRequest Working Draft was a Last Call Working Draft. As it turned out a number of changes had to be made again. Meanwhile HTML5 also got further along and integration with the event loop as well as the storage mutex was desired. These are now integrated. The Forms WG asked for a way to set the base URL independently of the Window object. This is now possible as a side effect of making XMLHttpRequest ready for Web Workers. Doug Schepers asked for separate headings for each interface member. This is now done as a side effect of making the two XMLHttpRequest drafts more alike. Given the number of changes it seems best to simply publish another Working Draft for now of both XMLHttpRequest and XMLHttpRequest Level 2 and see where that brings us. It would help if we have more implementations trying to seriously implement it so we could declare the draft more stable, but it seems we are not quite there yet. I'd like to request that we publish these two drafts: http://dev.w3.org/2006/webapi/XMLHttpRequest/ http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ If the chairs could wave their magic wand that'd be appreciated. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
[widgets] Draft Agenda for 13 August 2009 Voice Conf
Below is the draft agenda for the 13 August Widgets Voice Conference (VC).
Inputs and discussion before the meeting on all of the agenda topics
via public-webapps is encouraged (as it can result in a shortened
meeting).
-Regards, Art Barstow
Logistics:
Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00
Boston; 06:00 Seattle
Duration = 90 minutes
Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
IRC channel = #wam; irc.w3.org:6665
Confidentiality of minutes = Public
Agenda:
1. Review and tweak agenda
2. Announcements
3. A&E spec: proposal to publish LCWD
http://dev.w3.org/2006/waf/widgets-api/
4. P&C spec
http://dev.w3.org/2006/waf/widgets/
a. P&C Test suite dependency on A&E spec
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0522.html
b. Bug Alerts
Conformance checker behavior intermixed with UA behavior
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0552.html
http://www.w3.org/2008/webapps/track/issues/95
Try to fallback to default start files when src path is invalid or not existing
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0453.html
http://www.w3.org/2008/webapps/track/issues/94
deprecated, grandfathered, and redundant tags should be skipped.
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0452.html
http://www.w3.org/2008/webapps/track/issues/93
5. Modes spec
http://dev.w3.org/cvsweb/2006/waf/widgets-wm/
a. Work items needed to publish FPWD:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0218.html
6. AOB
Re: [XMLHttpRequest] withCredentials=false and returned cookies
On Wed, 12 Aug 2009 05:41:57 +0200, David Levin wrote: > It appears that both Safari and Firefox ignore returned cookies from a > cross origin xhr when the credentials flag is set to false. This behavior > seems very reasonable. > Should the XMLHttpRequest level 2 spec indicate that this is the expected > behavior? > Dave The editor's draft now states that cookies can only be set when the credentials flag is true. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XMLHttpRequest] question about default value of withCredentials
On Thu, 30 Jul 2009 20:38:24 +0200, David Levin wrote: > In http://www.w3.org/TR/XMLHttpRequest2/#credentials, it > says: "The credentials flag takes the values true and false, true by > default..." > Both Firefox and Safari have defaulted the value to "False" but the spec > says the default is "True". Given that these are the two implementations > out there, it seems that the spec should match them. > Thoughts? Agreed: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] events vs callbacks
On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking wrote:
> xhr.open("GET", myFile.slice(x, y).fileDataURI);
> xhr.send();
FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually think
that when using the filedata URL scheme some kind of exception needs to be
thrown. Similarly to when you would use mailto or something.
--
Anne van Kesteren
http://annevankesteren.nl/
ISSUE-95: P&C CR: Conformance checker behavior intermixed with UA behavior [Widgets]
ISSUE-95: P&C CR: Conformance checker behavior intermixed with UA behavior [Widgets] http://www.w3.org/2008/webapps/track/issues/95 Raised by: Marcos Caceres On product: Widgets On 11-Aug-2009, Marcos raised this Issue against the 23-July-2009 P&C CR: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0552.html
ISSUE-94: P&C CR: Try to fallback to default start files when src path is invalid or not existing [Widgets]
ISSUE-94: P&C CR: Try to fallback to default start files when src path is invalid or not existing [Widgets] http://www.w3.org/2008/webapps/track/issues/94 Raised by: Marcos Caceres On product: Widgets On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0453.html
ISSUE-93: P&C CR: deprecated, grandfathered, and redundant tags should be skipped [Widgets]
ISSUE-93: P&C CR: deprecated, grandfathered, and redundant tags should be skipped [Widgets] http://www.w3.org/2008/webapps/track/issues/93 Raised by: Marcos Caceres On product: Widgets On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0452.html
