[access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
I wanted to let the WG members know that we have completed our support for Access-Control in IE8 for the Simple Cross-Site Access Request. We support the Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the next public release of IE8, our Release Candidate, we have also added support for the string comparison to the ascii-origin. I want to thank the members of this group who gave us feedback about making this change. Making changes to our implementation now will be costly and I'd prefer if this part of the draft didn't have to change significantly. On the subject of renaming the Origin header, we'd prefer the option to keep it as is and have the name for CSRF changed in HTML 5 as Ian raised [1] if possible. Cheers, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0060.html -- Adrian Bateman Program Manager - Internet Explorer - Microsoft Corporation Phone: +1 (425) 538 5111 E-mail: mailto:adria...@microsoft.com
RE: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:ann...@opera.com] wrote: On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote: Jonas Sicking wrote on 1/14/2009 12:53 PM: The problem I think is that the current name, 'Origin', is extremely generic and so it's likely to cause confusion once we get other headers containing origins. What do other people think? I liked your suggestion that would marry the two: Jonas Sicking wrote on 1/12/2009 7:22 PM: That said, here is a solution that might work for both Access- Control and CSRF protection: Site A makes a request to site B, the UA adds the header Origin: A Site B redirects the request to site C, the UA adds the header Origin: A, B This would mean significant changes to the draft which would not work well for Microsoft. Renaming I would like to consider, changing the semantics drastically seems out of order at this point. Changing the semantics would unfortunately likely mean that IE8 would ship with behaviour that would be different to the spec. We probably won't be able to make that kind of change. I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. If the header name does change then we will cost out the work to make this change to see if we can do it. Clearly changing the strings used in the browser is a relatively constrained change but I'm concerned about the amount of churn in our test automation infrastructure that would be required and the risks involved. Cheers, Adrian.
RE: localStorage and IE8
Hi Ian,
Thanks for bringing the whatwg thread to our attention. We are aware of the
situation related to possible contention from different tabs or windows (which
may well be running in different processes in IE8) and our desire not to allow
one to block execution of another.
I will read through the mails and respond with our comments.
Cheers,
Ade.
--
Adrian Bateman
Program Manager - Internet Explorer - Microsoft Corporation
Phone: +1 (425) 538 5111
E-mail: mailto:adria...@microsoft.com
-Original Message-
From: public-html-requ...@w3.org [mailto:public-html-requ...@w3.org] On Behalf
Of Ian Hickson
Sent: Monday, March 23, 2009 4:25 PM
To: HTML WG; public-webapps@w3.org
Cc: Jonas Sicking; Anne van Kesteren; Cameron McCormack; Drew Wilson; Jeremy
Orlow; Michael Nordman; Oliver Hunt; Aaron Boodman; Robert O'Callahan; Dmitry
Titov; Adam Barth
Subject: localStorage and IE8
IE8 implements the localStorage feature of the Web Storage specification:
http://dev.w3.org/html5/webstorage/#storage
However, in a recent thread on the whatwg mailing list [1], it was noticed
that IE8 fails to implement the following requirement from the section
entitled 3.6 Threads:
# Multiple browsing contexts must be able to access the local storage
# areas simultaneously in such a manner that scripts cannot detect any
# concurrent script execution.
-- http://dev.w3.org/html5/webstorage/#threads
This can be demonstrated by opening two separate IE8 windows, navigating
both to the following URL:
http://software.hixie.ch/utilities/js/js-eval-window/
Typing the following into the first window:
localStorage.foo = 0;
while (true)
localStorage.foo = parseInt(localStorage.foo) + 1;
Typing the following into the second window:
var x = 0;
while (localStorage.foo == localStorage.foo)
x += 1;
x
...and then pressing the Evaluate... button in both windows.
In a compliant implementation, both would spin until the browser trips the
hung script limit. (Both scripts are effectively infinite loops; the
condition in the second script is guaranteed to be true by the condition
quoted above.)
In IE8, the second script will return in finite time, indicating that the
condition is not always true.
This leads to the possibility of race conditions, where scripts like this:
localStorage.pendingName = Fred;
// ...
if (localStorage.pendingName != n/a) {
output(Hello + localStorage.pendingName + !);
localStorage.pendingName == n/a;
}
...if run in two windows side by side, would sometimes lead to two
different calls to the output() method, one with Hello Fred! as
expected, and one with Hello n/a!, despite the check.
This is likely to be extremely hard for authors to debug.
This problem is exacerbated with Web Workers. It would be useful if
someone from the IE team could contribute to the aforementioned thread [1]
so that whatever solution is found is one that Microsoft would be willing
to implement.
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/thread.html#18907
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: File API Feedback
On Thursday, June 18, 2009 6:13 PM, Arun Ranganathan wrote: Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). I think the original discussion about this (re-reading IRC notes) was to have a short-lived URL (as locator, not as a Base64 dump) in the scope of the script that actually referred to the file. Upon reflection, Data URLs satisfy the use case for URLs to ... poke into parts of the platform that currently take only URLs. Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? I'd be concerned about the size. If you have a large file then exploding it into base64 just to copy it somewhere else into the platform where it will be decoded into yet another copy doesn't seem optimal. It may be a good v1 solution though. Ade.
RE: [webstorage] Ambiguous Requirement for Key Ordering
On Tuesday, June 09, 2009 6:57 AM, Lachlan Hunt wrote: Hi, The spec states [1]: The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object between changes to the number of keys. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) There is an ambiguity that can make that paragraph self-contradictory, depending on how the phrase [the order] must be consistent within an object between changes to the number of keys.. The ambiguity appears to be caused by the use of the word between in that context. I initially interpreted that as meaning that the order must remain consistent when the number of keys changes. But then this interpretation is contradicted by the parenthetical sentence following it. Please clarify. [1] http://dev.w3.org/html5/webstorage/#dom-storage-key I read it as meaning between the times when the number of keys changes the order must be consistent but I see the potential ambiguity. Perhaps the paragraph could be: The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object while the number of keys is unchanged. Adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not. Adrian.
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Adrian.
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 8:25 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol. IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Hi Adrian, thanks for the clarification. When you say it strips user credentials such as cookies, what about http auth info, client side certs, and referrer? Regarding the Origin header, how does XDR handle redirects? XDR is designed for accessing public resources. It passes no authentication information, requests for client certs are dropped, and since it's a one off request there is no referrer. If I recall correctly, the Origin header is sent for each step of the redirect and each 30x response (and the final response) is expected to include an Access-Control-Allow-Origin header with either the value * or a string match of the value of the Origin header.
RE: DataCache API - editor's draft available
On Thursday, July 16, 2009 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. [snip] / Jonas On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: I have published the first draft of the DataCache API, which is based on Oracle's BITSY proposal [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/DataCache/ Nikunj, thanks for putting together the document and publishing it. I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally. The other concern that I have is that this seems like an extension to the AppCache support in HTML 5. The new part is the ability to denote certain end-points that respond dynamically via script including supporting verbs other than GET. On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that? Cheers, Adrian.
RE: DataCache API - editor's draft available
On Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote: On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote: I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. There is a tradeoff when adding the complexity of unreliable networks - either more complex client application code, or more complex client interception code. In our experience, we have found the latter to be actually more manageable for cases where the interception and off-line serving is done in a relatively application-independent manner. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally. DataCache's interception pattern has existed for a while. A good survey of mobile data management and transaction support has covered this pattern [1]. The discussion there is not limited to Web browsers, though. I scanned through the paper you cite but it isn't clear to me which part of that is equivalent to your proposal. Is it possible to point out which section I should read more closely? The pattern that isn't familiar to me is one where it appears that application logic is provided by interception. Given the generic nature of the Mobile Transactions paper you focus on application independence, are you proposing that the DataCache is part of a solution with no application specific code? In other words is there some platform component, whether that be a JavaScript library or otherwise server-provided infrastructure, that operates generally at the interception point. Alternatively, is it application specific code that will be hand written for my use case every time? When Jonas asks the question about how do you expect people to use this, what comes to mind for me is a question about a scenario. I'm a web developer and I've built an application that makes XHR calls to exchange data with my server. I'd like to provide access to this application in situations where I am occasionally disconnected because of intermittent network connectivity. Do I now sit down and try to figure out what network requests I need to intercept and write JavaScript code for handling all of those requests? Or is there a library I can just plug in that, with some configuration, does that for me? Or is this something my server infrastructure should already support and if it does I just turn it on but otherwise I'm out of luck? Does the situation change if I am building an application from scratch that wants to deal with network disconnections? On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that? Yes. I certainly considered window.applicationCache. I have previously proposed including additional things in HTML5, but the feedback was that the application cache could not be broken down in to any further primitives due to bootstrapping requirements [3]. I certainly feel that applicationCache can be composed with the primitives of DataCache + versioning. On the other hand, the converse is not possible due to ApplicationCache's: a. strictly static manifest serving, b. lack of support for version-free resources, and c. missing authorization checks. [1] http://portal.acm.org/citation.cfm?id=992378 [2] http://o-micron.blogspot.com/2009/04/how-is-bitsy-different-from- html-dojo.html [3] http://lists.w3.org/Archives/Public/public-html/2008Nov/0224.html I understand that your DataCache proposal provides different functionality to AppCache. I wasn't suggesting that they were equivalent. However, the AppCache as specified is getting implemented today (it is in Safari and Firefox with other implementations on the way). The problem I have is that I can't go implement AppCache and then add on some new methods and alternative interception-path to get DataCache-like features - I have to write a completely independent mechanism. If I propose that we build AppCache and then DataCache, someone will say, Hang on, didn't we just build this - why do we need two? While it might not be the perfect solution (we know the web far from ideal and is a lot of compromise), this type of proposal would be a lot more compelling to me if I could say This is what we have to add, this is how, and here are the use cases that make it valuable with a roadmap for extending what people are already building instead of something brand new. Cheers, Adrian.
RE: DataCache API - editor's draft available
On Monday, July 20, 2009 1:43 PM, Nikunj R. Mehta wrote: On Jul 17, 2009, at 9:31 AM, Adrian Bateman wrote: On Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote: On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote: ... Does the situation change if I am building an application from scratch that wants to deal with network disconnections? In that case, you should be able to take advantage of the presence of interceptors and write your code to move to the client when client- side execution is desirable. If this application is used in environments that do not support interception, then it will work just fine with server-side execution. Of course, the application won't do the right recovery when it is disconnected if interception is not supported. Thanks for this and the preceding answers that I snipped. I'm not sure I find this model more compelling than the imperative equivalent, but okay. We can agree to disagree on which is more natural to web developers. I understand that your DataCache proposal provides different functionality to AppCache. I wasn't suggesting that they were equivalent. I am glad to see that you see a different set of functions offered in DataCache. Several commenters before you have taken the exact opposite position. I didn't interpret the other responses I read in that way but I may have mis-read them. I thought they were making a similar point to my next one. However, the AppCache as specified is getting implemented today (it is in Safari and Firefox with other implementations on the way). The problem I have is that I can't go implement AppCache and then add on some new methods and alternative interception-path to get DataCache- like features - I have to write a completely independent mechanism. If I propose that we build AppCache and then DataCache, someone will say, Hang on, didn't we just build this - why do we need two? OK. I get that. I also consider this to be an important challenge for everyone concerned. I thought I would write a concrete proposal. Oracle could help out with building a reference implementation for multiple browsers and make its source code available. What else can I do to help? I don't think the problem is that we couldn't build yet another cache that is similar but different to the AppCache that others are already shipping so I don't think a reference implementation is the solution. I think the problem is motivation - are there any use cases that adding DataCache enables that couldn't otherwise be implemented with what we already have and are those compelling enough to complicate the platform with another cache mechanism. Further, would we end up with conflicts between the AppCache and the DataCache since they're currently not unified as far as I can tell. While it might not be the perfect solution (we know the web far from ideal and is a lot of compromise), this type of proposal would be a lot more compelling to me if I could say This is what we have to add, this is how, and here are the use cases that make it valuable with a roadmap for extending what people are already building instead of something brand new. Would you mind explaining the last point with a roadmap for extending what people are already building instead of something brand new. for me? I would definitely strive to make the proposal more compelling. What I'm asking for is a more unified proposal that says If you have already implemented AppCache, here's what you add to make the same cache provide the additional functionality needed to enable these additional use cases. This will inevitably be a compromise from what a pure implementation looks like (your current DataCache spec, say) but lots of the web is necessarily a compromise because it builds on prior art that might not have been ideal but has been specified, built and deployed (and not always in that order). This would allow people to form a judgement about whether the additional use cases are worth the additional effort instead of whether the additional use cases are worth yet another cache. I think the ship has already sailed on AppCache and we can't undo that even if we wanted to and I don't think a competing solution is the right approach. Cheers, Adrian.
RE: DataCache API - editor's draft available
On Tuesday, July 21, 2009 11:26 PM, Nikunj R. Mehta wrote: On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote: What I'm asking for is a more unified proposal that says If you have already implemented AppCache, here's what you add to make the same cache provide the additional functionality needed to enable these additional use cases. This will inevitably be a compromise from what a pure implementation looks like (your current DataCache spec, say) but lots of the web is necessarily a compromise because it builds on prior art that might not have been ideal but has been specified, built and deployed (and not always in that order). This would allow people to form a judgement about whether the additional use cases are worth the additional effort instead of whether the additional use cases are worth yet another cache. I think the ship has already sailed on AppCache and we can't undo that even if we wanted to and I don't think a competing solution is the right approach. What kind of extensions/changes to AppCache would be acceptable at this point? In a previous exchange with Ian, he declined to consider DataCache like extensions to ApplicationCache for HTML5, which might be the reasonable thing to do. I can of course put together a proposal, but it would be good to know from browser vendors what their preferences are in this matter. I am open to the idea of incrementally evolving AppCache to be more supportive of DataCache requirements. At this point we haven't made a commitment one way or the other about whether we will implement support for AppCache in the next release of IE (or at all). It is supported in at least two shipping browsers and so we're naturally considering the possibility (along with a huge list of other possible features). I am confident that we won't implement a competing and unintegrated separate model, as Maciej put it, such as DataCache. As I've said, I think that would be a mistake. My preference would be to see this functionality proposed as an evolution of AppCache. While I can't commit that we would implement it any time soon, it would be included in our considerations and at the very least if we implement AppCache we would try to ensure any architecture we select wouldn't preclude these extensions in the future. With work on the HTML5 spec trying to get it locked down towards a Last Call, adding new features to that document is clearly less desirable and I understand Ian's reluctance to incorporate extensions there. I think a separate spec written here that proposes just the extensions and explains how it relates to the AppCache analogous to your DataCache spec would be appropriate but that's just my personal preference. Cheers, Adrian.
RE: [FileAPI] Latest Revision of Editor's Draft
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote: On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote: I would like to see implementation feedback on this. I don't understand why we would want to assign semantics to urn:uuid: URLs that are so specific -- that seems completely wrong. It also seems really awkward from an implementation perspective to forgo the normal extension mechanism (schemes) and have implementations give special (and non-trivial) semantics to a subset of another scheme. Why are we doing this? But like Arun, I suspect that this feature is the most controversial in the spec. Apple expressed concern about having a string represent a handle to a resource, and when we talked to Microsoft they briefly mentioned that they has concerns about this feature too, though I don't know specifically what their concerns were. The main concern I had was whether the URN feature was a must have for v1 given Arun's desire that this be the simplest spec that we could then build on later. Implementing a new protocol handler is more complex than just supporting the API part, for us anyway. I am also concerned about introducing new origin semantics - in the past this has been a source of security bugs and so I question whether we need to rush into this part (I accept the use case is valuable but I'm not sure it is initially essential). Cheers, Adrian.
RE: [FileAPI] Latest Revision of Editor's Draft
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote: On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman adria...@microsoft.com wrote: On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote: But like Arun, I suspect that this feature is the most controversial in the spec. Apple expressed concern about having a string represent a handle to a resource, and when we talked to Microsoft they briefly mentioned that they has concerns about this feature too, though I don't know specifically what their concerns were. The main concern I had was whether the URN feature was a must have for v1 given Arun's desire that this be the simplest spec that we could then build on later. Implementing a new protocol handler is more complex than just supporting the API part, for us anyway. I am also concerned about introducing new origin semantics - in the past this has been a source of security bugs and so I question whether we need to rush into this part (I accept the use case is valuable but I'm not sure it is initially essential). I'd really like to try to keep it in version 1. One of the use cases we hear most often for this API is for uploading images. For example to photo management sites like Flickr, but also for profile pictures on sites like twitter. In both these cases it's possible to use data-uris, but that will most likely result in the several copies of a several-MB-sized data-uris living in memory. I think the situation might be even worse in IE which if recall correctly there's some fairly low limits on how big data-uris can be (is this correct?). There is a limit on the size of data-uris in IE8 (32K I think). I expect addressing this will be a higher priority than a new handler but I agree that copying around large strings is problematic. Are you concerned about security bugs in the feature design or in the implementation? Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach. This isn't something I feel really strongly about. I imagine that when we look at implementing this we will start with just the API part and look at the URN handling separately. Cheers, Adrian.
RE: [FileAPI] Latest Revision of Editor's Draft
On Tuesday, November 03, 2009 10:07 AM, Arun Ranganathan wrote: Adrian Bateman wrote: On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote: Are you concerned about security bugs in the feature design or in the implementation? Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach. This feedback as a potential implementor is important :-) 1. Can you give us an example of an exploit, or expand on your concerns? If you look through the bugs reported (and fixed) in the Firefox jar: scheme handler many of them revolve around mishandling origin. The file urn is obviously simpler and also currently refers to a file that the user had to select. However, in future this might be used as part of a larger API that allows certain web sites to access certain files/folders. A vulnerability might involve leaking the URN from one origin to another allowing a site to read a file it shouldn't have access to. 2. From an implementation perspective, do you care whether we define a scheme (such as filedata:) or reuse something like urn:uuid:[UUID] ? Are there any barriers with respect to either one? At first glance, I imagine filedata: would be easier for us to implement but I haven't researched this yet - I will ask the question. I wonder from a spec perspective whether reusing urn:uuid: might cause problems with this being overloaded for different uses in future. Cheers, Adrian.
Microsoft pre-LCWD feedback on WebSocket API
Apologies for only sending this at the deadline. I have been collecting
feedback from a number of different groups at Microsoft who have been reviewing
the WebSockets API spec and only had chance to collate it today.
Feedback on Web Sockets API (draft dated 29 October 2009)
1) In the WebSocket constructor, we think it would make sense to limit the
optional protocol string to a set of characters that is easier to secure. The
UI never surfaces this string and having something that doesn't require
processing the full set of strings into UTF-8 shouldn't be a significant
restriction. We also think that specifying length constraints would be useful.
For example, stipulating the minimum length that conforming implementations
must be able to handle. One suggestion was to re-use the same criteria as a
valid scheme name as defined in section 3.1 of RFC 3986.
2) The second comment about the protocol string is editorial. There was quite a
lot of confusion about what the protocol string is used for and whether a
central registry would be needed for well-known protocol strings. I don't
believe this is intended or necessary but this suggests that the language could
be clearer. Perhaps an informative section describing the expected use of the
protocol string might be included.
3) The spec uses many terms that the HTML5 spec defines. As far as I can tell,
there isn't a definitive list of these. The 2.1 dependencies section notes that
many concepts come from HTML5 but not saying which ones seems insufficient for
spec moving to Last Call. Most of the people who looked at this spec had never
looked at HTML5 before and their feedback was simply that many terms were
undefined.
4) In step 2 of the UA steps for the WebSocket() constructor, the spec calls
for an exception to be thrown if the user agent chooses to block a well-known
port. We think that web developers will often miss this case because it will be
hard to test the error case and may be an unusual failure. We propose that the
UA signal this condition in the same way as failing to connect to a service
which will be much more common and more likely to be handled by web developers.
5) It is not clear precisely where the 'fail the Web Socket connection
algorithm' is defined.
6) The send() method can both throw an exception in the CONNECTING state or
return an 'error' flag if in the CLOSED state. APIs that both have return
values and also throw exceptions commonly cause coding errors by developers
using them. For example, here web developers may fail to deal with the
CONNECTING state because on their test service they get an almost immediate
connection but once they deploy hitting this case becomes much more common. We
recommend choosing between exceptions or return values but not both.
7) It is not clear exactly how to implement the bufferedAmount property and be
interoperable. Where is the queue of bytes not yet sent? Is this at the
application layer, in the networking stack, on the network card, or somewhere
else? We propose removing the bufferedAmount property.
I think we will have some other feedback more related to the wire protocol than
the API although changes to the protocol could potentially impact the API. I'm
not sure how the working group plans to handle this interaction between the API
draft and discussions elsewhere about the protocol (I understand there is a
proposal to deal with the protocol in an IETF working group?).
Cheers,
Adrian.
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Wednesday, November 04, 2009 5:46 AM
To: public-webapps
Subject: Seeking pre-LCWD comments for: Server-sent Events, Web {Database,
Sockets, Storage Workers}; deadline 19 November
As noted on 23 October [1], the following HTML5 APIs are ready or
very close to being ready for Last Call Working Draft (LC):
1. Server-Sent Events
http://dev.w3.org/html5/eventsource/
2. Web Database
http://dev.w3.org/html5/webdatabase/
3. Web Sockets API
http://dev.w3.org/html5/websockets/
4. Web Storage
http://dev.w3.org/html5/webstorage/
5. Web Workers
http://dev.w3.org/html5/workers/
Please submit comments about these specs by 19 November.
Note the Process Document states the following regarding the
significance/meaning of LCWD:
[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Purpose: A Working Group's Last Call announcement is a signal that:
* the Working Group believes that it has satisfied its relevant
technical requirements (e.g., of the charter or requirements
document) in the Working Draft;
* the Working Group believes that it has satisfied significant
dependencies with other groups;
* other groups SHOULD review the document to confirm that these
dependencies have been satisfied.
In general, a Last Call announcement is also a signal that the
Working Group is planning to advance the technical report
RE: Let's turn WebDatabase into a WG Note
On Wednesday, November 18, 2009 2:51 PM, Charles McCathieNevile wrote: I think it make sense to clarify in working drafts that this spec is unlikely to be interoperable across the web at large, but is usable for various specific systems. I don't think it makes sense to just turn it into a note at this stage - as the Google guys said, let's get some experience with WebSimpleDB before we make a final call. Likewise, I agree with Robin that it might not make sense to take this to Last Call, because of the uncertainty about where we are going to end up. I agree with Chaals. As I noted at TPAC, at Microsoft we don't think we'll collectively be able to achieve reasonable interop because of the SQL dialect issue (it's not like we can even choose one of the existing 'standard' SQL dialects since current implementations don't conform to anything like that). Considering that, it seems unlikely that there will be two independent interoperable implementations at the SQL level which makes moving to Last Call potentially problematic. On the other hand, it seems premature to dismiss the work entirely as a WG Note when more than one member has expressed a desire to move forward. I do wonder whether it might make sense to include an editor's note in the WD indicating that independent implementations of the SQL dialect aren't currently anticipated just so that anyone unfamiliar with this conversation would be aware from the spec. Cheers, Adrian.
RE: Let's turn WebDatabase into a WG Note
On Friday, November 20, 2009 4:44 AM, Charles McCathieNevile wrote: On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman adria...@microsoft.com wrote: ...As I noted at TPAC, at Microsoft we don't think we'll collectively be able to achieve reasonable interop because of the SQL dialect issue ... it seems unlikely that there will be two independent interoperable implementations at the SQL level which makes moving to Last Call potentially problematic... I expect to see interoperable implementations from Opera and Apple/Chrome - so although you can argue that iPhone-Safari and Safari are hardly independent, I think we will easily get a couple of truly independent interoperable versions. I was under the impression that Opera were using the same SQLite library as Apple/Google to provide the SQL implementation (obviously the JavaScript part Web Database API implementation would be independent). If that is not the case then I agree that they are independent however using the same library is a single implementation of the SQL dialect part of the spec. I do wonder whether it might make sense to include an editor's note in the WD indicating that independent implementations of the SQL dialect aren't currently anticipated just so that anyone unfamiliar with this conversation would be aware from the spec. I think the spec should be more careful, stating something like we do not currently anticipate that browsers will all implement the spec, and pointing to the WebSimpleDB as a *more likely* implementation based on current knowledge. That seems reasonable. Cheers, Adrian
RE: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Saturday, December 12, 2009 11:27 AM, Arun Ranganathan wrote: Charles McCathieNevile wrote: On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a Last Call Working Draft of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web SQL Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ This CfC satisfies the group's requirement to record the group's decision to request advancement to LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: Opera is not convinced that webdatabase is sufficiently clear and supported to be a last call draft. However we support the publication of the other drafts mentioned as last call working drafts. My personal position is the same as the above. While I support all the other specifications proceeding to LC, I think that more work needs to be done in order for webdatabase to proceed to the next step. Punting to a particular implementation (in this case, a version of SQLite) as a normative part of a specification is unprecedented in standards that this WG has released. At Microsoft, our position is similar on Web Database. We don't believe that relying on a particular version of SQLite is a good basis for long term interoperability. My opinion is that the database industry has spent a lot of time trying to standardise a dialect of SQL with only limited success and there's no reason to believe the WebApps working group is a good venue to try to do better. If this was a goal, we probably wouldn't start with the SQLite flavour of SQL either. We don't believe that the WebSockets API spec is sufficiently mature to move to Last Call. I don't think Many fundamental concepts from HTML5 are used by this specification is an adequate reference for the language included in a standalone W3C document intended to become a standard. Ian's recommendation to [use] the WHATWG complete.html version of the spec implies to me that the document is incomplete as it stands. Also, if the protocol and the API specs should be treated as part of the same thing even though published in different venues then doesn't it make sense to keep them in lock-step together? I'd appreciate some guidance from the chairs about whether they consider a document with this structure ready to move forward. Cheers, Adrian.
RE: to publish new Working Draft of Indexed Database API; deadline December 21
Microsoft supports publishing a new Working Draft. However, there appears to be a problem with the Respec.js script at http://dev.w3.org/2006/webapi/WebSimpleDB/. On Monday, December 14, 2009 12:54 PM, Arthur Barstow wrote: This is a Call for Consensus (CfC) to publish a new Working Draft of the Indexed Database API spec with a new short-name of indexeddb: http://dev.w3.org/2006/webapi/WebSimpleDB/ As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is 21 December. Since the comment period ends after the last day to request a 2009 publication, assuming this CfC is agreed, the new WD will be published 6 January 2010. -Regards, Art Barstow Begin forwarded message: From: ext Nikunj R. Mehta nikunj.me...@oracle.com Date: December 14, 2009 2:26:22 PM EST To: public-webapps WG public-webapps@w3.org Subject: Indexed Database API (previously WebSimpleDB) ready for a new WD Archived-At: http://www.w3.org/mid/981D8DE7-B1F3-4075-ACC6- a895c6665...@oracle.com Dear Chairs, Indexed Database API [1] is ready for a new WD. I have addressed various issues reported to the WebApps WG so far. I propose the short name indexeddb to replace websimpledb at this time. I know of one issue reported by Pablo Castro that is not resolved [2]: Usability of asynchronous APIs. This discussion needs its own time and more study to improve upon the approach currently in the ED. Thanks, Nikunj http://o-micron.blogspot.com [1] http://dev.w3.org/2006/webapi/WebSimpleDB/ [2] http://www.w3.org/mid/ f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.m icrosoft.com
RE: to publish new Working Draft of Indexed Database API; deadline December 21
On Monday, December 21, 2009 6:43 PM, I wrote: Microsoft supports publishing a new Working Draft. However, there appears to be a problem with the Respec.js script at http://dev.w3.org/2006/webapi/WebSimpleDB/. Apparently, the script takes some time to run (at least when I tried it in Firefox) and is incompatible with Internet Explorer. Is it possible to capture the result of the script running and publish that? Thanks, Adrian.
RE: to publish new Working Draft of Indexed Database API; deadline December 21
On Tuesday, December 22, 2009 2:39 PM, Nikunj R. Mehta wrote: Hi Adrian, I have published a non-JS version of the same document as the pub- ready WD. You can take a look at it: http://dev.w3.org/2006/webapi/WebSimpleDB/ I hope that works for you. Nikunj Looks good. Thanks Nikunj. On Dec 21, 2009, at 6:58 PM, Adrian Bateman wrote: On Monday, December 21, 2009 6:43 PM, I wrote: Microsoft supports publishing a new Working Draft. However, there appears to be a problem with the Respec.js script at http://dev.w3.org/2006/webapi/WebSimpleDB/. Apparently, the script takes some time to run (at least when I tried it in Firefox) and is incompatible with Internet Explorer. Is it possible to capture the result of the script running and publish that? Thanks, Adrian.
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
At Microsoft, we don't believe the spec is quite ready for Last Call. Based on our prototyping work, we're preparing some additional feedback that we think is more substantive than would be appropriate for Last Call comments. I anticipate that we will be able to post this feedback to the working group next Monday (25th Jan). From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Tuesday, January 19, 2010 9:48 PM To: Maciej Stachowiak Cc: Arthur Barstow; public-webapps; Jeremy Orlow Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 For what it's worth we are in the same situation at mozilla On Jan 19, 2010 3:40 PM, Maciej Stachowiak m...@apple.commailto:m...@apple.com wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow... We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
RE: [cors] Simplify CORS Headers (ISSUE-89)
In IE, we only support Access-Control-Allow-Origin and combining with other values (albeit optional ones) that we don't support might be misleading. It also introduces some additional parsing that changes the behaviour from a simple comparison to a more complex parse and then compare. We wouldn't be able to drop support for the current header so we'd need to support both and have a precedence order for which wins if both headers are present with different values. It's unlikely we'd issue a patch for IE8 unless there was strong customer demand and even if we did, there's no guarantee that it would be installed so services would still need to send both headers. I'm not all that keen on changing the names at this point either. Adrian. On Friday, May 14, 2010 10:19 AM, Arthur Barstow wrote: Simpler and/or shorter would indeed be good, although it may be too late. Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue? -Art Barstow On May 13, 2010, at 3:39 AM, ext Maciej Stachowiak wrote: On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote: I suggest we merge Access-Control-Allow-Origin, Access-Control- Allow-Credentials, and Access-Control-Max-Age into a new header, named CORS. The syntax of this new header would be: CORS : credentials? origin-value delta-seconds? I'm not that keen on changing the names, but if we do, I think CORS might be a bit mysterious by itself as a header name. Here's another set of naming suggestions, if we do go down the renaming path (which for the record I'd rather not): CORS == Allow-Access or Expose-Response CORS-Methods == Allow-Methods CORS-Headers == Allow-Headers (or Allow-Request-Headers) CORS-Preflight == can't think of a better name for this new header to expose more response headers == Expose-Headers (or Expose-Response-Headers) Regards, Maciej
RE: [cors] Simplify CORS Headers (ISSUE-89)
On Wednesday, May 26, 2010 1:05 PM, Adam Barth wrote: On Wed, May 26, 2010 at 9:08 AM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, May 24, 2010 at 8:23 AM, Adrian Bateman adria...@microsoft.com wrote: In IE, we only support Access-Control-Allow-Origin and combining with other values (albeit optional ones) that we don't support might be misleading. It also introduces some additional parsing that changes the behaviour from a simple comparison to a more complex parse and then compare. The above statement seems to imply that there are no plans for IE to support the optional features of CORS such as pre-flight and user credentials. Am I reading the statement correctly? I don't mean to speak for Adrian, but Microsoft doesn't usually comment on future product releases. I suspect that's because of various legal requirements in the US regarding forward-looking statements. Thanks Adam. To be clear, we currently don't support pre-flight/user credentials and we have not announced any plans to do so. I can't comment on what we might do in a future release. Thanks, Adrian.
RE: Updates to File API
On Wednesday, June 02, 2010 5:27 PM, Arun Ranganathan wrote: On 6/2/10 5:06 PM, Jian Li wrote: Indeed, the URL scheme seems to be more sort of implementation details. Different browser vendors can choose the appropriate scheme, like Mozilla ships with moz-filedata. How do you think? Actually, I'm against leaving it totally up to implementations. Sure, the spec. could simply state how the URL behaves without mentioning format much, but we identified in the past [1] that it was wise to specify things reliably, so that developers didn't rely on arbitrary behavior in one implementation and expect something similar in another. It's precisely that genre of underspecified behavior that got us in trouble before ;-) -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html Do you think the URL scheme should be specified for each use of Blob or more broadly? For example, Blob is used in the File Reader API but also possibly in the Capture API in a different way. It might be useful to be able to use a different scheme for these different purposes to help the user agent route requests to the appropriate handler. Adrian.
RE: Updates to File API
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? Cheers, Adrian
RE: Updates to File API
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote: On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? The one advantage I can see is that putting the scheme into the URL allows the *implementation* to deduce the origin by simply looking at the URL-scheme. This avoids having to do a (potentially cross-process) lookup to get the origin. This could be useful for APIs which have to synchronously determine the origin of a given URL in order to throw an exception on an attempted cross-origin access. For example an XMLHttpRequest Level 1 implementation needs to synchronously determine if it should make a call to .open(...) throw or not based on the origin of the passed in URL. However I'm not sure if this is a problem in practice or not. It's entierly possible that the web platform is littered with situations where you need to do synchronous communication with whichever thread the networking code runs on. Firefox is still in the process of going multi-process, so I'll defer to other browsers with more experience in this area. Oh, and I should add that the implementation will of course still have to check once a url is loaded that the origin in the url matches the origin in whatever map is used to map urls to resources. I.e. if the implementation has handed out a url like: filedata:sheep.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752 and script changes that to: filedata:wolf.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752 then attempting to load the latter url should result in a 404 or similar. Since the origin requires scheme as well as hostname/port it seems like we'll end up with some encoding or parsing complexity by following this approach. Robin gave good reasons for not allowing user agents to encode data into the URL and I'm not convinced that including origin for this particular case isn't a premature optimisation. At what point will we find other data that's convenient to have encoded in the URL? I think it makes more sense for the URL to be opaque and let user agents figure out the optimal way of implementing origin and other checks. Cheers, Adrian.
RE: Updates to File API
On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote: On 6/22/10 8:44 AM, Adrian Bateman wrote: I think it makes more sense for the URL to be opaque and let user agents figure out the optimal way of implementing origin and other checks. I think it may be important to define: * Format. I agree that this could be something simple, but it should be defined. By opaque, do you mean undefined? * Behavior with GET. For this, I propose using a subset of HTTP/1.1 responses. I think we agree. I actually meant well-defined but opaque to JavaScript consumers. In other words script in a web page can't deduce any meaningful information from the string. If we're aiming for that property then it makes sense that the entire scheme be defined (something like filedata:----000). We can bikeshed the scheme name later but I'd prefer something more generic now url is off Blob. I agree that there should be HTTP/1.1 response codes for GET. Cheers, Adrian.
RE: Updates to File API
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote: I agree with you Adrian that it makes sense to let the user agent figure out the optimal way of implementing origin and other checks. A logical step from that premise is that the choice/format of the namespace specific string should be left up to the UA as embedding information in there may be the optimal way for some UA's of implementing said checks, and it sounds like other UAs may not want to do that. Robin outlined why that would be a problem [1]. My original feeling was that this should be left up to UAs, as you say, but I've been convinced that doing so is a race to the most complex URL scheme. Cheers, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html
Lifetime of Blob URL
On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote: On 6/23/10 9:50 AM, Jian Li wrote: I think encoding the security origin in the URL allows the UAs to do the security origin check in place, without routing through other authority to get the origin information that might cause the check taking long time to finish. If we worry about showing the double schemes in the URL, we can transform the origin encoded in the URL by using base64 or other escaping algorithm. Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url allows you to do that, without obliging other UAs to do that. Some UAs may elect to use smart caching to accomplish the same kinds of things, without tagging the URL with origin information. Others may see benefit in origin-tagging. I've reconsidered trying to architect a scheme that allows all use-case scenarios for blob: URIs. Hi Arun, I think the updated URL section reflects a good compromise. We might want to call out explicitly that opaque string should not include recognisable metadata to avoid scripts from trying to parse the URL. User Agents that wish to include data such as origin should do so by encoding it in an opaque manner. I have one other concern about the lifetime of the blob URL [1]. The spec currently says that blob: URLs should have the lifetime of the Document. I think this is too long. An AJAX style web application may never navigate the document and this means that every blob for which a URL is created must be kept around in some form for the lifetime of the application. In our discussions on this topic at Microsoft we've assumed that the lifetime for a blob URL will be the same as the lifetime of the blob itself. This does create something of a race condition. If I have a blob representing an image where I set the src of an img element and then let the blob go out of scope might it be collected before the img loads the resource? We think we'll have to include some mechanism to ensure that the blob and URL doesn't get collected before pending network requests have been made. This does impose an additional burden on the web developer: if they later want to copy the source URL from one img to another then this will only work if they also kept the blob in scope somewhere. What do you think? Cheers, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
RE: Lifetime of Blob URL
On Monday, July 12, 2010 8:24 AM, David Levin wrote: On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com wrote: Making the blob url identical to the lifetime of the blob itself would expose when garbage collection takes place and in general could lead to easy to make mistakes in which the developer had something that work mostly but not always -- your situation below is just one of them. Check out the Jian Li's alternate proposal (see his response to Re: [File API] Recent Updates To Specification + Co-Editor on July 1, I think) that addresses this in a way that addresses your concerns and the gc issue as well. The problem with an explicit revoke call is that people need to know to call it, need to actually call it, and need to know when it is appropriate to call. Many of the same timing issues that cause potential problems with GC also make it hard for web developers to know when to call revoke. When GC occurs is indeterminate and would vary greatly between browsers. Developing features which exposes the gc behavior would lead developers into accidentally relying on browser specific behaviors (which may even break for the same browser during upgrades). The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. As I read Jian's proposal, there is a create call (blob.url would go away), so there would clearly be a revoke (or destroy call). With respect to timing issues, the behavior of revoke with respect to load is clearly defined in his proposal which result in very deterministic behavior. My apologies. I think I missed this part - please can you provide a link to the full proposal? At what point after I assign the src of an img element can I call revoke? Can I do it immediately after the assignment or do I have to have an onload and onerror handler for every element that uses it? With XHR do I have to wait for readyState 4 or can I call revoke earlier in the process? Is there reference counting so that if I call create twice I have to call revoke twice? Thanks, Adrian.
RE: Lifetime of Blob URL
On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com wrote: The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. Yes. Unfortunately, another way of saying that the url lives as long as the Blob lives is the url lives until the Blob is garbage collected. This exposes a very indeterminate behavior. Exactly. So what I'm saying is the spec needs to say more than just that. It needs to make further guarantees. http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an img? Isn't this similarly indeterminate. Regards, Adrian.
RE: Lifetime of Blob URL
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote: On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.com wrote: I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an img? Isn't this similarly indeterminate. As soon as img.src is set. the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. Should apply to xhr (after send is called), img, and navigation. Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. -Darin It sounds like you are saying the following is guaranteed to work: img.src = blob.url; window.revokeBlobUrl(blob); return; If that is the case then the user agent is already making the guarantees I was talking about and so I still think having the lifetime mapped to the blob not the document is better. This means that in the general case I don't have to worry about lifetime management. Adrian.
Blob/File naming
On Monday, August 30, 2010 1:09 PM, Jonas Sicking wrote: On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com wrote: *sigh. Naming continues to be hard. Not everyone's thrilled with the proliferation of Blob in the API [1] including other major implementors (my co-editor included ;-)) but I changed it mainly due to Darin/Jian/other objections. I suppose you folks are pretty adamant on the Blob* name? I feel pretty strongly that we should name this back to FileReader, for several reasons: 1. Most people that I talk to dislike the name Blob, much less having it spread to things like BlobReader. 2. My understanding is that the writer counterpart is going to be called FileWriter (is this correct?) 3. While it's certainly possible to read Blobs with this, it seems to me like the far most common case will be to read a real file, or part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader It's easy to bike shed on naming and I don't really want to get into that. I'd prefer we just settled on something and stick to it. However I will offer some observations from the conversations we've been having on this topic. I like the abstraction of Blob away from File with File being a concrete implementation of the Blob interface. I suspect going back to just File adds a bunch of unnecessary things to the cases where the data isn't file backed. It seems there are a proliferation of specs that reference the Blob concept. In fact the confusion in my conversations with people over the name has been about a Blob here being more like a Stream than what they traditionally think of as a BLOB (with a url property for example). We think using Blobs with XHR and IndexedDB, say, will become at least as common as their use for reading files from the file system. Cheers, Adrian.
RE: Blob/File naming
On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote: 1. Most people that I talk to dislike the name Blob, much less having it spread to things like BlobReader. I could maybe understand this if blob were a new term we were inventing. But it's not. It's a well-known computer science concept. It seems worse to try and coin a totally new name for opaque chunk of data. FWIW, most people hating the name blob seems like a stretch, as it has not been my experience. But maybe we run in different circles. This was addressed to me although quoting Jonas. One of the problems I've experienced is that in general the well-known computer science concept doesn't have a URL that can be used to stream data into another object. It's feasible to use the Blob interface in circumstances where the bits of the blob aren't manifested until they are actually used. Some concepts from the Media Capture API seem to be heading in this direction. That said, I don't have a problem with the name Blob. :o) Cheers, Adrian.
RE: FPWD of Web Messaging; deadline November 13
Microsoft supports publication of a FPWD of Web Messaging. On Saturday, November 06, 2010 11:49 AM, Arthur Barstow wrote: Ian, All - during WebApps' November 1 gathering, participants expressed in an interest in publishing a First Public Working Draft of Web Messaging [1] and this is a CfC to do so: http://dev.w3.org/html5/postmsg/ This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is November 13. -Art Barstow [1] http://www.w3.org/2010/11/01-webapps-minutes.html#item04 Original Message Subject: ACTION-598: Start a CfC to publish a FPWD of Web Messaging (Web Applications Working Group) Date: Mon, 1 Nov 2010 11:35:29 +0100 From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group WG public-webapps@w3.org To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com ACTION-598: Start a CfC to publish a FPWD of Web Messaging (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/598 On: Arthur Barstow Due: 2010-11-08
RE: Discussion of File API at TPAC in Lyon
On Thursday, November 11, 2010 11:47 AM, Jonas Sicking wrote: Oh, definitely, we still need the createObjectURL/revokeObjectURL functions. Sorry, that was probably unclear. However we're still left without a place to put them. Maybe it's as simple as putting them on the document object? That works nicely since their lifetime is scoped to that of the document object. Another possibility is putting them on the URL interface object. I.e. not using URL objects themselves, but rather something like this: x = URL.createObjectURL(myblock); typeof x == string; URL.revokeObjectURL(x); But I think I prefer the document solution. I thought we'd decided on a new global object and just needed to come up with a name. This is what we're currently planning to do. Mostly though, I just want us to decide. This seems to have changed every month for a long time and I'd like us to pick a solution and stick to it. From http://www.w3.org/2010/11/02-webapps-minutes.html#item16 jonas: the proposed solution is some global object where we put 2 functions anne: is there some existing place we could put them? sam: maybe window.blob? but you want to do it for stream too so maybe that's not a good place ericu and others: k, let's move on
RE: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
We're okay with this too, especially if it doesn't change. :)
RE: Structured clone in WebStorage
On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. Adrian. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Wednesday, February 23, 2011 8:21 AM, Arthur Barstow wrote: Anne and Ms2ger (representing Mozilla Foundation) have continued to work on the DOM Core spec and they propose publishing a new Working Draft of the spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html As such, this is a Call for Consensus (CfC) to publish a new WD of DOM Core. If you have any comments or concerns about this proposal, please send them to public-webapps by March 2 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. I think the document should have a clearly stated goal relative to DOM L3 Events. Currently it describes building on DOM L3 Core and DOM L2 Events. Anne described adding events to the draft last week [1] but it's not clear to me what the benefit of redefining the Event interface in this document is when W3C is proceeding with DOM L3 Events on the Recommendation track. If there are things that need to be clarified specifically for browsers and similar user agents then perhaps a profile of DOM L3 Events would be better. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html
Binary data in WebSockets API (was RE: [Bug 12102] New: WebSocket protocol update time)
As we've been updating our WebSockets prototype [1] in line with the latest protocol changes we've been thinking about how the binary support that the protocol now includes should be reflected in the API. I added the following comment to the bug: At Microsoft, we've been reviewing how the binary support now enabled by the WebSocket protocol might be exposed in the API. In line with Ian's notes in this bug, we'd like to see the send() method accept a Blob argument that indicates to the API that a binary message should be sent. The existing definition with a string should send a text message. Implementations can decide how they choose to break up the message into intermediate frames since this isn't exposed to the API. On the receiving side, we think that the event.data attribute should contain a Blob if the message was a binary message and a remain as a string for text messages. Since MessageEvent already defines data to be of type 'any', the change here would be to describe the semantics of text vs. binary messages in section 5 of the spec. For the send method, we'd expect an overload of send in section 4 as follows: void send(in Blob data); We'd be interested to hear how others have been thinking about this. Thanks, Adrian. [1] http://html5labs.interoperabilitybridges.com/prototypes/available-for-download/websockets -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of bugzi...@jessica.w3.org Sent: Wednesday, February 16, 2011 5:52 PM To: public-webapps@w3.org Subject: [Bug 12102] New: WebSocket protocol update time http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 Summary: WebSocket protocol update time Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: i...@hixie.ch QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org * onclose should have unsigned int reasonCode and DOMString reasonMessage. * readonly attribute DOMString extensions; // ianf will provide a hook * send() takes some sort of binary argument and * onmessage event.data exposes binary data * check through http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol to make sure the hooks still work -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Thursday, February 24, 2011 2:37 PM, Anne van Kesteren wrote: On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman adria...@microsoft.com wrote: I'm concerned about the working group endorsing a working draft with phrasing like The timeStamp attribute must be useless. I understand there are issues related to this (e.g. ISSUE-172) but this doesn't seem like a professional way to approach them. It's a funny way ;-) And it has a red marker pointing out the problems. And as stated in the Status of this Document section publication does not imply endorsement. Of course it's true that the status doesn't imply everyone agrees with everything and I'm okay with that but heartbeat working drafts are intended to show forward progress and this feels like a retrograde step to me compared to the previous draft. This should be updated to reflect the discussions for ISSUE-171 and ISSUE-172. I think the document should have a clearly stated goal relative to DOM L3 Events. I thought that would be inappropriate since DOM Level 3 Events is still in development. We discussed this at TPAC and decided that DOM Core would do things in parallel and based on that we would figure out which is the better approach once both are somewhat more stable. However, relative to DOM Level 3 Events the differences are identical. So if that would remove your objection I can change the 2 to a 3. Since DOM L3 Events is further along and likely to track faster than this spec it would be reasonable to refer to this. The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I'd prefer issues like this to be resolved before endorsing them in a Working Draft. Working Drafts are there to share ideas with the wider world. They are not endorsed. Last Call Working Drafts and beyond are supposed to be checked carefully. Letting the wider world comment on this idea is exactly what I would like; to see if it's a good idea. It would be nice if you could suggest some approach as to how we could resolve this timely. If this is your intent then it would be helpful to include a note in the draft making this clear so people know to give this kind of feedback. Otherwise it is just confusing to see it defined in two different places. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Thanks for your consideration, Adrian.
RE: publish a new Working Draft of DOM Core; comment deadline March 2
On Friday, February 25, 2011 1:54 AM, Anne van Kesteren wrote: The idea is to provide a better definition of the events model at a more appropriate location. I do not think DOM Level 3 Events is the right way forward, but I am happy to work in parallel to see which turns out better in the end. This is a fair goal but my feedback is that it would be better to find a way to build on or enhance DOM L3 Events than to ignore it. I have studied it while writing the Events chapter actually. However it did not always provide all the answers, as indicated e.g. by Ian and also by my email announcing the addition. My preference is to not have two drafts in the WebApps working group with conflicting specification of the same feature. If there is feedback or clarifications that need to be added to DOM L3 Events we should make sure that happens. Where would you like the note to be located? Do you have preferred wording? Something like this maybe: DOM Core provides an alternative definition for the 'DOM Event Architecture' and 'Basic Event Interfaces' chapters of DOM Level 3 Events. We would appreciate your input on which approach you prefer. Something boxed out at the start of the Events section would be great for now. Hopefully we can make sure that the drafts are aligned and if the new DOM Core spec picks up where DOM L3 Events leaves off then that might be an helpful outcome. I think it's important for us to get DOM L3 Events to done to capture all the work that has been done over the last decade before moving on to something new. I'll also say for the record, since you're asking about this, that Microsoft's view is that keeping Event in DOM L3 Events is the best approach but that a profile elsewhere if necessary is fine. Changes along these lines would help show forward progress as intended by a heartbeat draft and then I would happily endorse this call for consensus to publish. Cool! Thanks for considering the feedback, Adrian.
RE: publish Last Call Working Draft of Progress Events spec; deadline March 7
Microsoft supports this. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, March 02, 2011 4:08 AM To: public-webapps Subject: CfC: publish Last Call Working Draft of Progress Events spec; deadline March 7 Given no comments were submitted during the 2-week pre-LC comment period [1] for the Progress Events spec, this is a Call for Consensus to publish a Last Call Working Draft of this spec based on the latest Editor's Draft: http://dev.w3.org/2006/webapi/progress/Progress.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is March 9. Please send all comments to: public-webapps@w3.orgmailto:public-webapps@w3.org Assuming there is consensus to publish this LCWD, the tentative plan is to publish it on March 10 with a the LC comment period ending June 1. -Art Barstow
RE: publish Last Call Working Draft of Web Workers; deadline March 7
Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of the web worker lifetime model (Section 4.4),
dedicated
workers are allowed to enter into an orphaned state where they have a message
port
that is keeping them alive (see example at the end of this feedback). We can
imagine
scenarios where the orphaned workers are still able to provide results to a
document
(e.g., via connecting to a shared worker), however these use cases 1) seem
largely
irrelevant, 2) can be handled by shared workers if needed and 3) overly
complicate the
implementation (in our analysis) of dedicated workers.
We note that no browser appears to implement the lifetime model as specified in
the
latest editor's draft (that we can test).
As we've investigated potential alternate lifetime models (for dedicated
workers only),
we came up with two additional potential models:
1 - Lifetime based on a dedicated worker's document reachability
This alternate lifetime model keeps a dedicated worker alive until it can no
longer
communicate with the document(s) to which it is associated (through its
implicit port
or any other port). This proposed lifetime model is based on graph
reachability, where
the nodes in the graph are web workers and the arcs in the graph are implicit
and
explicit message ports owned by a worker (i.e., the worker's ports). A
dedicated
worker's lifetime is managed by whether the dedicated worker can reach the
document(s) in its list of the worker's documents. See the example at the end
for
how the currently speced lifetime model changes with this approach.
2 - Lifetime that prevents orphaning dedicated workers
In this alternate lifetime model, orphaned dedicated workers are never allowed,
and
the lifetime of the worker is strictly controlled by its implicit port.
Therefore,
whenever a worker creates another worker, if the parent worker is terminated
or
closed, then the child worker will be terminated or closed as well
(preventing the
child from becoming an orphan). This model is enforced regardless of other
message
ports that the child may have.
It is our opinion that the lifetime model for dedicated workers as currently
speced:
1. Overly complicates the implementation
2. Supports corner-case scenarios that have questionable mainstream benefit,
compared to the perception of the currently specified design being
considered a
bug (e.g., the web developer creates a scenario where the orphaned worker
remains
alive, but did not actually intend for this to happen)
3. Provides overlapping scenarios with shared workers (e.g., if the web
developer
really intended the dedicated workers to remain alive as orphans, then
they could
use a shared worker to accomplish the same task instead)
We ask that this feedback be considered and are specifically looking for
1) a justification of the scenarios enabled by supporting dedicated workers in
an
orphaned state and 2) scenarios we may not have considered where an orphaned
dedicated
worker could not be substituted for a shared worker to accomplish the same task.
Should a change to the spec be made as a result of this feedback, we would
propose
that alternate lifetime model #2 above be considered instead (not allowing
orphaned
dedicated workers). Alternate approach #1, while less of a change, is
considerably
harder to implement than #2 given the graph reachability problem involved.
It is also worth noting that current versions of Opera appear to implement the
dedicated worker alternate lifetime model #2 above, though we don't know what
decisions led to that conclusion from their point of view.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are parent workers and W2 and W4 are child
workers.)
5. W1 creates a message channel and passes the channel's ports to document
'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to document
'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's ports to
'W2' and 'W4'
(W2 and W4 now have a direct communication channel between themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be disentangled [step 15 of
section 4.5
processing model] which effects W2's implicit port; however, W2 is not
terminated
because it is still considered a protected worker, since its list of the
worker's
ports is not empty.)
9.
RE: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10
Microsoft supports this CfC. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Thursday, March 03, 2011 5:26 AM To: public-webapps Cc: Mark Nottingham; Julian Reschke; Nikunj Mehta Subject: CfC: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10 Hi All, WebApps' Programmable HTTP Caching and Serving spec was last updated by Nikunj in January 2010. Since then, my attempt to determine the level of interest in this spec via the tread below (archived at [1]) received no real traction. As such, this is a Call for Consensus to formally stop work on this spec. More specifically, the proposal includes: 1. Moving the spec from the PubStatus' active API Specifications table [2] to the Specs NO Longer Active table [3] 2. Marking its Plans data with Work on the specification has ended 3. Removing it from WebApps' charter the next time the charter is renewed (current charter ends June 2012) Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is March 10. Please send all comments to: public-webapps@w3.orgmailto:public-webapps@w3.org -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0447.html [2] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [3] http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active Original Message Subject: [DataCache] Status and plans for Programmable HTTP Caching and Serving? Date: Fri, 5 Nov 2010 14:26:13 +0100 From: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.commailto:art.bars...@nokia.com To: public-webapps public-webapps@w3.orgmailto:public-webapps@w3.org, Nikunj Mehta nik...@o-micron.commailto:nik...@o-micron.com, Bernard Traversat bernard.traver...@oracle.commailto:bernard.traver...@oracle.com, Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de, Mark Nottingham m...@yahoo-inc.commailto:m...@yahoo-inc.com Hi All, During WebApps' November 1 gathering at the TPAC, we discussed [Mins] the WG's Programmable HTTP Caching and Serving spec, last updated by Nikunj in January 2010 [DataCache]. During this discussion, I agreed to the following related actions: ACTION-599 Ask Nikunj to report the status and plans of Programmable Cache to public-webapps http://www.w3.org/2008/webapps/track/actions/599 ACTION-600 Ask Oracle about their level of interest in Programmable Cache http://www.w3.org/2008/webapps/track/actions/600 ACTION-601 Ask public-webapps about creating Use Cases and requirements of Program App Caches versus HTML5 App Cache http://www.w3.org/2008/webapps/track/actions/601 ACTION-602 Contact julian reschke and Mark Nottingham about Data Cache http://www.w3.org/2008/webapps/track/actions/602 My short summary of this discussion is: it isn't clear if there is sufficient interest to continue this spec and if there is interest, what are the specific use cases it will address (i.e. use cases not addressed by HTML5 AppCache), and who is willing to commit to drive the spec forward. -Art Barstow [ tracker tags: ACTION-599, ACTION-600, ACTION-601, ACTION-602 ] [Mins] http://www.w3.org/2010/11/01-webapps-minutes.html#item05 [DataCache] http://dev.w3.org/2006/webapi/DataCache/
[FileAPI] Result of calling MultipleReads on FileReader
As we continue to experiment with the File API, I'm trying to understand the rationale for the Multiple Reads section: http://dev.w3.org/2006/webapi/FileAPI/#MultipleReads The spec says: If multiple read methods are called on the same FileReader object, user agents MUST only process the last call to a read method, which is the call that occurs last in a script block that has the already started flag set [HTML5]. I'm trying to understand the rationale for respecting the LAST call - is it common for people to call read lots of times and want the last one to be respected. Since the read happens asynchronously, we'd rather kick off the read operation as soon as the first read is called and give an error to subsequent read calls. I'm not sure what the use case is for wanting the last one (you can always call abort() and start again). Is there a reason for the current spec text? Thanks, Adrian. -- Adrian Bateman Program Manager - Internet Explorer - Microsoft Corporation Phone: +1 (425) 538 5111 Email: mailto:adria...@microsoft.com
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote: On 3/30/11 2:01 PM, Eric Uhrhane wrote: On Mon, Mar 28, 2011 at 5:37 PM, Adrian Batemanadria...@microsoft.com wrote: Is there a reason for the current spec text? I don't know the original rationale, but in the absence of any strong technical constraint, I'd much prefer that subsequent read calls just throw an exception immediately. They seem likely to be indicative of bad code anyway, and it's so much easier to debug when you find out right away. The original rationale was to do what XHR does w.r.t. open()! Essentially, the goal was: 1. To abort previous reads in favor of the last one, like how XHR does. 2. The last read goes through. So: Adrian/Eric -- do you object to keeping this like XHR in terms of aborting previous reads? What I should *definitely* do is make spec. text more robust to reflect this; in general I want to make asynchronous parts of this spec. more like HTML5 here. As long as the spec is clear I don't mind whether a subsequent read throws or includes an implicit abort() call. That's not the way I read the current spec text. We need to know things like whether we should queue any events for the abort or just silently move on to the new read, etc. It would be good if we can be explicit about when you're allowed to call readAs (this way it sounds like always) and if anything is different between the LOADING and DONE states. Thanks, Adrian.
RE: [websockets] What needs to be done before the spec is LC ready?
On Tuesday, April 05, 2011 4:27 AM, Arthur Barstow wrote: Hi All, What needs to be done before the WebSocket API is LC ready? Bugzilla has three open bugs for this spec: 1. API for send/receive of binary data? Current IETF protocol drafts have binary type. Consider typed arrays (ArrayBuffer). http://www.w3.org/Bugs/Public/show_bug.cgi?id=11834 2. WebSocket protocol update time http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 3. The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? ... http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 We've made some proposals in the 12102 bug based on our prototyping with this API. As we work through this I expect we'll also have feedback on areas we think need additional detail to ensure interoperability by different implementers. I've included our recent feedback below, quoted from the bug. Adrian. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 There are use cases for both Blob and ArrayBuffer. While it's possible to convert between the two it's also convenient to be able to specify the preferred type just like with XHR, which supports both. Supporting both would require a mechanism to specify the preferred type. In fact, as we've been experimenting with the WebSocket API we've found that initiating network I/O from the constructor is somewhat inconvenient. We would much prefer a model more like XHR and feel that this is better for future extensibility as the API develops. Our proposal to start the discussion: * The constructor behavior and signature is changed to follow the XHR model. It instantiates a WebSocket object but does not establish the connection. * A new ready state constant is added to indicate that a WebSocket has been created, but no connection established. * A new open method is added to the API to establish the connection: void open(in DOMString url); * A supportedProtocols attribute is added. This is the list of protocols sent by the client to the server during the handshake. This replaces the protocols parameter in the current constructor. attribute DOMString[] supportedProtocols; * Add overloads to send void send(in Blob data); void send(in ArrayBuffer data); * A binaryResponseType attribute is added to the WebSockets interface which can be set to: arraybuffer or blob. The default string might default to ArrayBuffer or it might indicate that the client isn't expecting binary data. We'd like to discuss this more. attribute DOMString binaryResponseType; * Message event event.data returns a string for text messages and the type specified in binaryResponseType for binary data. Message event only fires when the entire message is available.
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote: On 3/31/11 6:12 PM, Eric Uhrhane wrote: I think it's cleaner and simpler just to throw. FileReader and XHR are already different enough that a bit more, as long as it's a usability improvement, isn't a big deal. The efficiency improvement is just a bonus. Eric: are you sure you mean throw or do you mean, fire error event or abort? Note that only FileReaderSync (running on threads) actually throws in terms of an exception. I think throwing an exception would be appropriate here. The FileReader will know synchronously that it is already doing a read and that calling read again is an invalid operation. Firing the error event should be reserved for errors that come from the operation of the reader and not because the developer called it incorrectly. Cheers, Adrian.
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote: On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I agree with Eric - I prefer to fail fast when the developer has misused an API. It makes it much easier to see that there is a mistake and debug why. So the key question to me is Is this misuse? I can't think of a good use case where a developer would want to call read again during the LOADING state and expect that the correct behaviour would be to implicitly call abort(). That doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect sense - that makes FileReader reusable - but during LOADING I think is a developer mistake. Cheers, Adrian.
RE: publish new Working Draft of Indexed Database API; deadline April 16
On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote: The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Microsoft supports this.
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote: FileReader is extremely similar to XMLHttpRequest. The main difference is in how you initiate the request (.open/.send vs. .readAsX). This similarity is even getting stronger now that XHR gets .result. So I think there are good reasons to sticking to XMLHttpRequest here too. Note that no error events are fired by XMLHttpRequest. Just an abort event. So error is still reserved for actual reading errors whereas abort will fire for script-initiated aborts. I agree that calling .readAsX multiple times could be an indication of developer bugs and as such could throw an exception. However I think given the precedence set by XMLHttpRequest it could just as well mean that a new resource is now the one that the author is interested in reading. With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Cheers, Adrian.
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote: On 4/15/11 2:57 PM, Adrian Bateman wrote: With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Adrian: I'm keen to have behavior similar to XHR, and not raise an exception in this case. From your note above, I'm gathering you can live with an XHR-style abort which FileReader can fire on readAsXXX calls that have been superseded. Yes, we could live with it but the semantics are more complex. Is this the same as calling abort() then readAsXXX()? When does the abort event get queued? What will be the state of the reader at this point? Will loadend get fired? It needs careful speccing to make sure that the details are handled the same in different implementations. Adrian.
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com
wrote:
Yes, we could live with it but the semantics are more complex. Is this the
same as calling abort() then readAsXXX()?
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress)
abort();
... start new reading ...
}
When does the abort event get queued? What
will be the state of the reader at this point? Will loadend get fired? It
needs careful speccing to make sure that the details are handled the same in
different implementations.
Calling the abort() fires the abort and loadend events before the
function returns. Likewise readAsX fires the loadstart event before
it returns. So if a load has already started, then readAsX fires,
before it returns, the following events in order:
abort, loadend, loadstart
But indeed, the spec needs improvements here.
Does loadstart fire synchronously or asynchronously (presuming the first two
fire
synchronously?)?
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman adria...@microsoft.com
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress)
abort();
... start new reading ...
Calling the abort() fires the abort and loadend events before the
function returns. Likewise readAsX fires the loadstart event before
it returns. So if a load has already started, then readAsX fires,
before it returns, the following events in order:
abort, loadend, loadstart
But indeed, the spec needs improvements here.
Does loadstart fire synchronously or asynchronously (presuming the first
two fire
synchronously?)?
All three fire synchronously. I.e. all three events fire before the
readAsX function returns.
Currently the spec says Queue a task to dispatch a progress event called
loadstart. Is that incorrect or just different when restarting a read?
Adrian.
RE: CfC: WebApps testing process; deadline April 20
First, thanks to Art for pulling all this content together. We're looking forward to a more structured process for testing as various specifications in the WebApps increase in maturity. I have a couple of small comments related to the issues Aryeh raised. Apologies for the lateness of these comments; I spent time sharing this process with a number of teams at Microsoft before responding. 1. Early approval of tests We think that waiting for Last Call or Candidate Recommendation before approving tests loses some of the value of tests in driving ambiguity out of the specification. The CSS WG found many issues in CSS 2.1 as a consequence of tests and some of these issues we substantive enough that the spec went back to Working Draft status. Avoiding this by reviewing test cases earlier in the process will help to improve spec quality. I think of this in the following way: a bug filed against the spec requesting a change represents someone's view that the spec is wrong. On the other hand, an approved test with consensus of reviewers in the working group helps to identify more stable sections of the spec. It doesn't mean it can't change but it does mean the spec has had additional review on the assertions made in the test and that's useful. 2. Calls for Consensus When a contributor submits a set of tests, hopefully members of the public-webapps-testsuite list will review them. When the contributor believes they have addressed all of the feedback on the tests, we think they should be able to put the tests forward for a Call for Consensus on approving them. The WG may choose to issue such a call on a regular schedule for tests that have had sufficient time for review if the number of submissions makes doing this on demand too cumbersome. This call may just be made to the testsuite mailing list. A full WG consensus shouldn't be necessary until document transition. 3. Test suite maintainer It's not clear from the discussion below what the role of the maintainer is and whether there's one per spec or one for the group. This seems like largely an administrative role in ensuring that the appropriate tests are moved into the approval folder at the correct time and that the status of the test suite is accurately recorded. Perhaps members of the working group could volunteer to help with this or maybe the Team could help. Microsoft would be willing to contribute here too. Thanks, Adrian. On Tuesday, April 19, 2011 9:22 AM, Arthur Barstow wrote: I agree the need for clear test suite status is implied and should be explicit. I've added a new requirement for this to [1]. As to how this requirement is addressed, perhaps we should adopt/re-use some existing good practice; otherwise perhaps we can use a Status/Readme file in each .../tests/ directory. Besides WG Approval, you see the need for maintainer approval. Additionally, you think there will be scenarios where multiple submissions make it difficult to know which tests have been reviewed (e.g. by the maintainer). This could be addressed by the maintainer creating a separate directory (e.g. reviewed) and the maintainer would use it to place copies of test cases (e.g. from submissions directories) she reviewed (and possibly edited and approved). I don't think the process as currently defined would preclude the maintainer from doing something like this and if it becomes a common/good practice, we could document it. In the case of a single contributor, it's probably not something that would be needed (but wouldn't necessarily be harmful). -Art Barstow [1] http://www.w3.org/2008/webapps/wiki/Testing#Testing_Goals On Apr/17/2011 7:06 PM, ext Aryeh Gregor wrote: On Wed, Apr 13, 2011 at 10:02 AM, Arthur Barstowart.bars...@nokia.com wrote: I have updated WebApps' testing process documents to reflect comments submitted to the initial draft process [1]. As such, this is a Call for Consensus to agree to the testing process as described in: http://www.w3.org/2008/webapps/wiki/Testing http://www.w3.org/2008/webapps/wiki/Submission http://www.w3.org/2008/webapps/wiki/Approval http://www.w3.org/2008/webapps/wiki/Harness Sorry for the lateness of this review -- I was swamped with work and didn't find the time to respond earlier. I still have a few issues with the proposed approval procedure. The way it sounds is that tests can either be non-approved, or approved. Non-approved tests sound like (I'm not totally clear on this) they're supposed to live in per-contributor submission/ directories, without anyone else necessarily having any say over them. Approved tests, on the other hand, only exist at LC or later, and can't be changed without Working Group approval. (Which means what? I'm not sure.) The problem I've seen with the submission/ vs. approved/ approach in the HTMLWG is that there's no distinction between tests in submission/ that are useful and correct but just haven't been reviewed by anyone,
[websockets] Binary support changes
I'm pleased to see the changes in the WebSockets API for binary message support. I'm a little confused by this text: When a WebSocket object is created, its binaryType IDL attribute must be set to the Blob interface object associated with the same global object as the WebSocket constructor used to create the WebSocket object. On getting, it must return the last value it was set to. On setting, if the new value is either the Blob or ArrayBuffer interface object associated with the same global object as the WebSocket constructor used to create the WebSocket object, then set the IDL attribute to this new value. Otherwise, throw a NOT_SUPPORTED_ERR exception. I don't entirely follow what this is saying but we'd prefer the binaryType to be a DOMString in the same fashion that the responseType is in XHR2. Is there a reason for this to be an object? We'd prefer consistency. Thanks, Adrian.
RE: [websockets] Binary support changes
On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote: However, I think there might be another solution to this whole situation. There really is no reason that only binary data can be received as a Blob. Getting data as a Blob is useful any time you're dealing with a large chunk of data where you're not immediately going to process all (or even any) of the data. Hence it would make sense to allow also text data to be received in the form of a Blob. So maybe a better solution is to simply add a boolean flag which indicate if data should be received in a plain format (strings for textual data, ArrayBuffer for binary), or as a Blob (which would have its .type set to text/plain;charset=utf8 or depending on if it's textual or binary). I don't really like this idea. I don't want to have to change the way I read text messages just because I want binary data as a Blob. One of the scenarios are planning for is a text message that contains meta data about subsequent binary messages that will be treated as Blobs. Your proposal would require extra complexity to read text from a Blob or switch back and forth. Adrian.
RE: [websockets] Binary support changes
On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
On Fri, 27 May 2011, Jonas Sicking wrote:
For example, what is an implementation supposed
to do if a page does:
ws.binaryType = otherwindow.ArrayBuffer
or
otherwindow.useThis(ws);
with other window containing
function useThis(ws) {
ws.binaryType = Blob;
}
The spec actually defines this (it throws unless it's the same Window's
as the WebSocket object's, currently).
What I would really like to use is an actual type type, but JS doesn't
have those.
Additionally, how will webpage code check if a websocket connection
is currently set to using blobs or arraybuffers if it needs to deal
with the case that the connection is potentially coming from another
global?
Currently, it needs to use the source global's interface objects.
This seems to add unnecessary complexity both to web developers needing to keep
track of the source global and to the implementation's type system where we
have to go through additional hurdles to get back to the objects in another
context. It might look pretty to use the interface object but a string is just
simpler and not entirely unfamiliar to web developers. For example, canvas
getContext is somewhat similar.
Adrian.
[websockets] Constructor vs. open()
As I proposed in March [1], we think it makes sense to separate the WebSocket constructor from the operation to initiate the network operation. We proposed a separate open() method similar to XHR. This allows a WebSocket object to be constructed and initialised prior to communication. We think this makes the design more future-proof because otherwise and new information required prior to establishing the connection will need to be added to the constructor arguments. I'm interested to know how other implementers feel about this proposal. Thanks, Adrian. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102#c9
RE: [websockets] Reintroducing onerror
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote: On Tue, 7 Jun 2011, Adrian Bateman wrote: We have removed onerror from our implementation since the previous change and it's frustrating trying track against the spec with unexpected updates. That's the cost of being on the bleeding edge. It's very likely that it will change again. Until we have implementation and authoring experience, we will almost certainly continue to update the specification to address new problems and use cases. If you want to implement things that don't change, then wait til someone else has implemented it and shipped it. Being on the bleeding edge means you are providing the feedback that affects the specification's development. I'm just asking for a little transparency here: as far as I can see there were no bugs filed or public e-mail discussion on this nor was there any explanation in the check-in to change the spec. We understand that things change but we're hoping that we're getting close to Last Call and we'd like an opportunity to participate in the discussion before things show up unexpectedly at this point. Thanks, Adrian.
RE: [websockets] Reintroducing onerror
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote: On Tue, 7 Jun 2011, Adrian Bateman wrote: This check-in [1] reintroduces the onerror handler that was removed previously [2]. Since, in general, WebSocket protocol errors are fatal and result in onclose, what is the purpose of adding this back? Ian asked me to put it back so that authors can distinguish between a server closure and a client-initiated error-driven closure. What is the difference between these two cases? When would onerror fire that wouldn't result in onclose with wasClean=false? Isn't the wasClean flag sufficient? Thanks, Adrian.
RE: [Bug 12913] New: Close() should throw the same exception as send() for unpaired surrogates
On Friday, June 10, 2011 7:05 AM, Arthur Barstow wrote: Adrian - this bug is for the Web Sockets API spec (and not Web Storage), correct? On Jun/8/2011 1:21 PM, ext bugzi...@jessica.w3.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12913 Yes - corrected now, thanks!
RE: RfC: moving Web Storage to WG Note; deadline June 29
On Wednesday, June 22, 2011 3:24 PM, James Robinson wrote: On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that there are currently major browsers that do not follow the spec as currently written and have explicitly said that they have no plans to do so. If browsers can agree on what to implement, update the spec to reflect that. If they can't and we don't think they ever will, update the spec to say behavior is undefined. Either way, it's no less worthy of REC-track specification than other preexisting features that are flawed but in practice not removable from the platform. I think browsers are relatively speaking closer in implementation to each other than to the spec currently. Would it be too much work to come up with a specification that did not include the structured clone algorithm and did not include the storage mutex? That seems to be what browsers need to support for compatibility, and so it would be ideal to capture that in some form. Such a specification would have inherent and unavoidable data races (as do current and future implementations), so it would be a stretch to consider it recommended, but it would reflect reality. I agree - the current API isn't ideal but it is what it is and there is reasonable interoperability at this point. Microsoft would prefer not to see the spec move to WG Note status and instead see the spec modified to reflect the current implementations: removing the SCA, removing the mutex, and adding a warning about the race conditions would get us most of the way. There are certainly uses of this feature where the race is unlikely to cause a problem. Cheers, Adrian.
RE: [XHR2] Blobs, names and FormData
Just catching up with this thread. We ran into the same problem last week while investigating FormData and XHR. Since FormData is designed to allow XHR to interact with existing form end-points that usually required a navigation, we've found that few of them have been tested with empty filenames. On Wednesday, June 29, 2011 9:35 AM, Alfonso Martínez de Lizarrondo wrote: All I want is a way for the web page to state that when a Blob is used in a FormData object it should be send to the server with a proposed filename. No sniffing. No guessing. It's up to the script to suggest a correct filename (if it wants), or use whatever is the default filename used by the browser (Blob23g22g3024j23g209gj3g and the like, extensionless) My first simple approach was: formdata.append(elementName, blob, picture.png); Jonas has suggested instead blobbuilder.getFile(picture.png) I don't mind one way or another, or something else you think it's better. I was about to send a similar proposal. We'd prefer to add an optional argument to append that specifies the filename. This is the smallest change to implementations and doesn't require developers to understand the BlobBuilder in order to use FormData. Having to create another reference to a Blob and probably deal with managing a File and Blob both pointing to the same data seems unnecessarily involved when all we want is to get the filename into the FormData object. On Thursday, June 30, 2011 12:28 AM, Julian Reschke wrote: On 2011-06-29 18:34, Alfonso Martínez de Lizarrondo wrote: ... No. All I want is a way for the web page to state that when a Blob is used in a FormData object it should be send to the server with a proposed filename. No sniffing. No guessing. It's up to the script to suggest a correct filename (if it wants), or use whatever is the default filename used by the browser (Blob23g22g3024j23g209gj3g and the like, extensionless) ... In which case there should also be a way to send the actual media type, no? Yes, the blob has a content type so the correct type can also be sent.
[FileAPI] FileReader.readAsXXX when pased null
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file What is the expected behaviour for FileReader.readAsXXX(null)? Currently I think both IE10 and Chrome fail silently and there are no events fired whereas Firefox appears to throw an internal NS_ERROR_INVALID_POINTER exception. The spec doesn't seem to state this explicitly and I can't tell if there is supposed to be an implicit requirement from WebIDL. Perhaps the expectation is that this falls into the error condition and should set readyState to DONE, result to null, and process the error steps? Any thoughts? Adrian.
RE: publish Last Call Working Draft of Web IDL; deadline July 7
Microsoft supports publishing a Last Call working draft of the Web IDL spec. We believe that the spec is feature complete and meets the requirements below. While we have a few reservations about Exceptions and share some of the concerns voiced in the separate thread on that topic, we believe that can be dealt with as Last Call comments. On Thursday, June 30, 2011 3:46 AM, Arthur Barstow wrote: As Cameron indicated in [1], all non-enhancements bugs for Web IDL are now resolved and as such, this is a Call for Consensus to publish a Last Call Working Draft of Web IDL: http://dev.w3.org/2006/webapi/WebIDL/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is July 7. Please send all comments to: public-script-co...@w3.org -Art Barstow
[websockets] Getting WebSockets API to Last Call
We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor 10213 - The definition of absolute url makes https:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.
RE: [websockets] Getting WebSockets API to Last Call
On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman adria...@microsoft.com wrote: 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. I agree with the WONTFIX here. I think optional parts of specifications is a bad thing in the web space and bad for interoperability. If we really end up needing the ability to set optional parts we can always add that in the future. I agree with the general principle of not adding optional features. However, I think this case is different for a couple of reasons: 1) This is optional in the protocol spec. If you don't think it should be optional in the protocol that argument should be made in the IETF working group. I don't agree that the W3C API should override the discussions in the protocol working group just because some people don't like the outcome. 2) This feature is an extension point. Its sole purpose is to support optional features. Mandating one example of an extension seems arbitrary to me. As soon as there is another extension there will still be differences. We believe that there will be legitimate implementations that don't want to support deflate-stream and servers will have to support with and without to be conforming anyway. 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. I don't agree with making binaryType immutable, and I added a comment to that effect to the bug. I did also put in another proposal in the bug which also aims to reduce implementation complexity and improve performance. Thanks for the feedback on this one. It would be good to get a sense from other implementers about how there feel here. Cheers, Adrian.
RE: [FileAPI] FileReader.readAsXXX when pased null
On Thursday, July 07, 2011 10:21 PM, Arun Ranganathan wrote: On 7/6/11 10:13 PM, Cameron McCormack wrote: There was a recent change in Web IDL which made interface types (like the readAsXXX argument types) not include null by default, and if you want to allow null, to write it as “Type?”. If you don’t change the type in the File API spec to include the question mark, then Web IDL defines it so that passing null means a TypeError will be thrown. If you want to do some additional processing beyond throwing an exception (e.g. setting readyState), then you would need to allow null by using “Blob?” as the type and then say what happens when null is passed in. Wow, not only do I stand corrected, but I'm also gladdened :) This change to WebIDL is a good one, and I'm sorry I missed it when it came out. Adrian: this should answer your original question, although I still think that in general, user agents differ pretty substantially over the type of exceptions that are being thrown (and this is yet another example). Hopefully this is something we can fix with updates. Yes, thanks. I think this is probably a good change although I'm worried that there might be specs that allow null and don't realise they need to update to Type?. Hopefully, if there are any, they'll be found when their dependency on WebIDL is reviewed. Adrian.
[websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote: 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. I strongly disagree. We must have interoperability amongst browser user agents. Having some support compression and others not would lead to authoring mistakes and will force us into either having or not having compression based on how big sites first get this wrong. It's fine to disagree, but you should disagree in the IETF working group where this is made optional and not in the Web API. There will be other users of WebSockets outside the browser and by implementing the protocol they won't be required to implement this extension. In addition, there are still discussions about whether this is an appropriate mechanism for compression since it requires intermediaries to decompress the whole stream if they want to review messages. There are still proposals to remove deflate-stream from the spec. We think there are legitimate cases for implementing the protocol without compression. That aside, however, we strongly disagree with one consumer of a protocol, the Web API, making decisions to override the requirements of the protocol spec. Adrian.
RE: [XHR2] Blobs, names and FormData
On 11 July 2011 10:53, Jonas Sicking wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman adria...@microsoft.com wrote:
Some content management systems use the original filename by default
when storing files in document libraries. It's certainly a lesser use case
but seems like a relatively trivial change to the API. I don't see it as
sugar, since it's not possible to achieve this on the client in any other
way.
I've proposed adding the following function to BlobBuilder:
interface BlobBuilder {
...
File getFile(in DOMString name, [optional] in DOMString contentType)
...
};
This will let you accomplish the same thing in just 2 additional lines
of javascript (one of which can be reused).
Well, yes, there are multiple ways of proposing a solution. My point was there
is no easy way to do this without adding some functionality somewhere (I don't
consider manually constructing a multi-part message a simple approach). I don't
like the BlobBuilder solution because it adds the notion of needing to link the
same underlying blob data to both a Blob and File, which suggests an extra
level of abstraction in the implementation. I'm not sure what other use case
there is for getFile and I prefer the more isolated simpler fix to FormData.
RE: [XHR2] Blobs, names and FormData
It requires more work for us. Our createObjectURL doesn't require that
abstraction. The difference here is in the ECMAScript type. In contrast,
modifying FormData append is a trivial change.
What are the other APIs where this is a problem?
Sent from my Windows Phone
From: Charles Pritchard
Sent: 11-Jul-11 12:03 PM
To: Adrian Bateman
Cc: Jonas Sicking; Anne van Kesteren; Julian Reschke; Alfonso Martínez de
Lizarrondo; Webapps WG
Subject: Re: [XHR2] Blobs, names and FormData
getFile could work with dataTransfer for dropping files onto the desktop. There
may be other Apis which work with File but not with Blob, or not as well with
Blob.
Blob already requires linking/abstraction from createObjectUrl. Internally,
getFile could simply run createObjectUrl and treat it as a named file. I doubt
this would require much additional work from implementers.
-Charles
On Jul 11, 2011, at 11:00 AM, Adrian Bateman adria...@microsoft.com wrote:
On 11 July 2011 10:53, Jonas Sicking wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman adria...@microsoft.com
wrote:
Some content management systems use the original filename by default
when storing files in document libraries. It's certainly a lesser use case
but seems like a relatively trivial change to the API. I don't see it as
sugar, since it's not possible to achieve this on the client in any other
way.
I've proposed adding the following function to BlobBuilder:
interface BlobBuilder {
...
File getFile(in DOMString name, [optional] in DOMString contentType)
...
};
This will let you accomplish the same thing in just 2 additional lines
of javascript (one of which can be reused).
Well, yes, there are multiple ways of proposing a solution. My point was
there is no easy way to do this without adding some functionality somewhere
(I don't consider manually constructing a multi-part message a simple
approach). I don't like the BlobBuilder solution because it adds the notion
of needing to link the same underlying blob data to both a Blob and File,
which suggests an extra level of abstraction in the implementation. I'm not
sure what other use case there is for getFile and I prefer the more isolated
simpler fix to FormData.
RE: [XHR2] Blobs, names and FormData
On Monday, July 11, 2011 12:46 PM, Charles Pritchard wrote: Problem is too strong a statement. I am all for trivial changes, part of my advocacy for getFile is from past experiences when blob was less supported; getFile would have helped. FileReader has base64 encoding for binary data-- base64 encoding otherwise only works on DOMString. I'd like to see both proposals implemented... Then I get everything! On Jul 11, 2011, at 12:21 PM, Adrian Bateman adria...@microsoft.com wrote: It requires more work for us. Our createObjectURL doesn't require that abstraction. The difference here is in the ECMAScript type. In contrast, modifying FormData append is a trivial change. What are the other APIs where this is a problem? Our view is to see everything here as a Blob. A File is a specialisation of Blob that happens to have a name and modified date. If there is an API that replies on File to work correctly we think we should fix it to work with Blob. For example, FileReader is really BlobReader and works fine with Blobs. To me, getFile() should be unnecessary and the best fix for FormData is to just modify append for this situation. Adrian.
RE: [XHR2] Blobs, names and FormData
On Monday, July 18, 2011 12:52 PM, Michael Nordman wrote: The problem is around naming the binary parts attached to multi-part-form-encoded FormData. I think I'm in favor of the more direct solution to this problem, providing a FormData.append() variant that optionally allows the caller to specify a name. If no name is provided and the blob is a File, the filename is used, otherwise a non-empty value generated by the client is used. formdata.append(elementName, blob, picture.png); BlobBuilder.getFile() as a solution to this particular problem is less direct (and less obvious and less discoverable so less friendly). And it raises questions like... Is the blob data really flattened out as a file on the disk somewhere? If not, then getFile() is somewhat misleading. Is so, we may have to create actual files when we otherwise wouldn't. Where is this file created? When does it get deleted? +1 I agree completely.
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote: On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com wrote: What do others (Anne?, Maciej?, ...) think about this issue? I don't know enough about the WebSocket protocol, but optional web platform features suck. They will become mandatory following the typical dominant implementation does it and we want to work on the same sites scenario. For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. There is still discussion in the IETF about whether stream or frame based compression is best. That's the right place to have that discussion. There are also implementers that want extensions for other things, such as multiplexing. This is a protocol layer handshake below the API and the API simply provides information about what was agreed. Adrian.
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote: On Thu, 21 Jul 2011, Adrian Bateman wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Optional features in HTTP have caused no end of trouble and are amongst the many reasons I avoid optional features so much. What specific problems have been caused by the existence of extensions (separate from whether or not extensions have been well defined) and what API consequences have there been i.e. what changes to web APIs have you made because of this? It seems to me that HTTP has been wildly successful and its extensibility is a large part of that. In any case, that's a distraction - the W3C Web API should specify the things needed to project the protocol into the web developer's hands and no more. Discussions of the protocol, which is in Last Call, should be made in the appropriate working group at the IETF. There's no need to profile the protocol in the W3C API spec. Adrian.
RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote: On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com wrote: For platform features that directly affect web developers' pages that might sometimes be true. However, compression is also optional in HTTP and it doesn't appear to have caused problems or made some sites work and others not based on some dominant implementation. Do you think it would be feasible in practice for a mainstream web browser to not support HTTP compression? For instance, if Internet Explorer removed support for it, would you expect to get a sufficient number of bug reports that you'd be forced to re-add support? If so, then HTTP compression is in practice mandatory for web browsers, but optional for web servers. This is exactly the state of affairs proposed for WebSockets compression. First, I don't think that's the same thing at all. Second, the IETF HyBi working group has asked members of this working group for Last Call feedback. If you think the protocol has the wrong mix of required/optional features then you should provide that feedback through the requested channel. Adrian.
RE: publish Last Call WD of Progress Events; deadline August 2
Microsoft supports this CfC. On Tuesday, July 26, 2011 7:13 AM, Arthur Barstow wrote: The pre-LC comment period for Progress Events resulted in no comments [1]. As such, Anne proposes a new LC be published and this is a CfC to do so: http://dev.w3.org/2006/webapi/progress/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is August 2. Please send all comments to: public-webapps@w3.org Assuming there is consensus to publish this LCWD, the tentative plan is to publish the LC on August 4 with a 3-week LC comment period (ending August 25). -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1249.html
RE: Rescinding the DOM 2 View Recommendation?
On Wednesday, August 10, 2011 10:18 AM, Arthur Barstow wrote: Anne, Ms2ger, All, Anne and others proposed in [Proposal] the DOM 2 View Recommendation [D2V] be rescinded. The rescinding process is defined in the Process Document [Rescind]. However, Ian Jacobs just indicated in IRC [#webapps] it has never actually been used. One process requirement for rescinding a Recommendation is a separate rationale for the proposal to rescind. Would you Anne and/or someone please create the rationale document (using WebApps' wiki)? I think it should include a clear problem statement i.e. identify the interop issues this Recommendation is causing as well as the alternative (new) solution. If anyone has comments about this proposal, please speak up. Microsoft is opposed to rescinding the DOM L2 View Recommendation. Our customers value stable Recommendation documents that they can use to compare implementations against and we document Internet Explorer's variations against all completed W3C Recommendations. For IE9 we targeted the DOM L2 View spec and our support documentation is available in MSDN [1]. Trying to maintain such documentation for a moving target such as the HTML5 spec is too costly and doesn't provide our customers with what they need. Microsoft proposes that the W3C maintain the Recommendation status for DOM L2 View until a stable alternative is available. A note in the status section indicating that on-going work to supersede this document is being done in the HTML5 specification would be appropriate. [1] http://msdn.microsoft.com/en-us/library/ff460623(v=VS.85).aspx
RE: publish new WD of DOM Core; deadline August 10
On Monday, August 15, 2011 2:22 AM, Anne van Kesteren wrote: On Thu, 04 Aug 2011 21:21:46 +0200, Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman adria...@microsoft.com wrote: The name was changed. We weren't terribly keen on the change. It is now causing problems. I've had multiple people contact me confused about this. We should fix the problem. Alright, how about DOM4? Adrian, could you please answer the question? Not participating at all in the development of DOM Core, then objecting when publishing, and then not responding when I try to suggest alternative ways to move forward is not a nice way to cooperate within a WG. Hi Anne, My apologies for not replying more promptly. I'm representing Microsoft here and not only my personal views and you'll appreciate that sometimes it takes a little time to organise this. I'm sure the same applies at Opera too so thanks for your patience. It's harder to participate without understanding the scope of the problems being solved. As I wrote in the separate thread to Art, we prefer a scoped spec where we've agreed which problems we're trying to solve rather than something open ended. DOM4 seems a bit too unbounded in that context but agreeing on the goals for this spec, be it Core or something else will help answer the questions. I think there are some good ideas in this spec including some things that will be helpful to developers to have written down. We spent a lot of time while we were building IE9 testing to see which parts of the DOM specs were applicable to the browsable web platform. This is something we will continue to help with though our immediate priority is helping to move DOM L3 Events forward. Cheers, Adrian.
RE: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Thursday, August 11, 2011 3:29 AM, Arthur Barstow wrote:
[ Topic changed to how to organize the group's DOM specs ... ]
Hi Adrian, Anne, Doug, Jacob, All,
The WG is chartered to do maintenance on the DOM specs so a question for
us is how to organize the DOM specs, in particular, whether Anne's DOM
spec should be constrained (or not) to some set of features e.g. the
feature set in the DOM L3 Core spec.
There are advantages to the monolithic/kitchen-sink approach and, as we
have seen with other large specification efforts, there aredisadvantages
too. In general, I prefer smaller specs with a tight{er,ish} scope and I
think there should be compelling reasons to take the monolithic
approach, especially if there is a single editor. Regardless of the
approach, the minimal editor(s) requirements are: previous credible
experience, technical competence in the area, demonstrated ability to
seek consensus with all of the participants and willingness to comply
with the W3C's procedures for publishing documents.
In the case of AvK's DOM spec, there has been some progressive feature
creep. For instance, the 31-May-2011 WD included a new chapter on Events
(with some overlap with D3 Events). The 2-Aug-2011 ED proposed for
publication includes a new chapter on Traversal. Additionally, the ED
still includes a stub section for mutation events which is listed as a
separate deliverable in group's charter (Asynchronous DOM Mutation
Notification (ADMN)).
Before we publish a new WD of Anne's DOM spec, I would like comments on
how the DOM specs should be organized. In particular: a) whether you
prefer the status quo (currently that is DOM Core plus D3E) or if you
want various additional features of DOM e.g. Traversal, Mutation Events,
etc. to be specified in separate specs; and b) why. Additionally, if you
prefer features be spec'ed separately, please indicate your willingness
and availability to contribute as an editor vis-à-vis the editor
requirements above.
At Microsoft, we also prefer smaller more specific specifications for all
the same reasons that it makes sense to engineer software in smaller, more
modular parts.
* It is easier to implement and test smaller modules. Developers find it
easier to focus on one thing and it is easier for testers to do a thorough
job of preparing a test suite.
* While it is a little harder to make well-defined interfaces between
modules/specs, doing so is part of the engineering process that ensures a
good design.
* It's much easier to measure done when dealing with a smaller spec.
Moving the specification through the stabilisation process, getting complete
implementations, and achieving interoperability is easier when people are
focused on the same set of features. A larger, more monolithic spec always
leads to discussions about which parts are stable or unstable, which are
implemented and how well.
I think it's healthy to debate what should in or out of scope for a
particular document. Ideally this should be based on a set of requirements
or goals for the features. For example, it might be a goal to document the
profile of the DOM that is actually interoperable and in use on the Web
today. It might be a goal to add new features to this DOM that reduces the
amount of code necessary to perform a set of common tasks. It might be a
goal to add capabilities that improve performance of certain scenarios
popular in script libraries.
Microsoft is prepared to contribute more editing resources to the DOM
space once we establish the scope and structure of the future work.
Jacob has been assisting Doug with DOM L3 Events and moving this forward
is our highest priority here.
Cheers,
Adrian.
RE: rename DOM Core to DOM4; deadline Sept 9
On Wednesday, September 07, 2011 9:53 AM, Arthur Barstow wrote: It appears the majority of the people that voiced an opinion on this thread prefer DOM4. If anyone objects to DOM4, please speak up by September 9 at the latest and include the rationale for your objection as well as an alternate proposal. Microsoft supports this proposal. I normally try to stay away from discussions about naming but this was one where we received feedback that it was important to change. I want to thank the group for giving this issue due consideration. Cheers, Adrian.
New tests submitted by Microsoft for WebApps specs
Today we shipped Microsoft Internet Explorer 10 Platform Preview 3 as part of the Windows 8 Developer Preview. Alongside this release, we have submitted interop tests for several WebApps specs for review by the working group: WebSockets API (101 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/6712344ae119 Tests: http://w3c-test.org/webapps/WebSockets/tests/submissions/Microsoft/ Indexed DB (87 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/62fbeaa2ed43 Tests: http://w3c-test.org/webapps/IndexedDB/tests/submissions/Microsoft/ WebWorkers (51 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ Notes: * The tests all use the common test harness developed initially in the HTML WG and adopted by the WebApps WG in the test submission guidelines. * Since these are the first submitted tests for each of these specs, we created new folders for them in the webapps folder. * We believe the tests are all accurate but look forward to wider review from the group. IE10 PP3 does not pass all the tests and we are working to fix the bugs that cause failures. * The Indexed DB tests include code to work around the current vendor prefixing. At some point we will need to remove this code from the official test suite but it makes running the tests simpler for now. * The WebSockets API tests require a running service. We are currently hosting the service on a Microsoft server (html5labs-interop.cloudapp.net). We are committed to working with the W3C systems team and this working group to host the service at the W3C when this is possible.
RE: publish a LCWD of Web Socket API; deadline September 27
Microsoft supports this call. On Tuesday, September 20, 2011 4:05 AM, Arthur Barstow wrote: This is a Call for Consensus to publish a Last Call Working Draft of the Web Socket API using the following document as the basis: http://dev.w3.org/html5/websockets/ As noted in [1], this spec has two editorial bugs and one bug that some group members do not want to address for this version of the spec. The Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is September 27. Please send all comments to: public-webapps@w3.org. If any new bugs are submitted before this CfC completes and the LC is published, those bugs will be will be considered as LC comments. -Art Barstow [1] http://lists.w3.org/Archives/Public/public- webapps/2011JulSep/1484.html
Draft Proposal for Streams API
There has been discussion in this group now and again about the need for stream support as part of the File APIs including recently in the threads about Streaming Blobs [1] and XHR streaming [2]. I've also had several private conversations with members of the WG about the need we see for this kind of stream support. Initially, we thought that supporting a streaming Blob was the correct solution but we ran into a number of issues with this as we investigated further. First of all, people were confused about using the term Blob to represent something of unknown size. Secondly, we received guidance from a number of people to keep the two concepts of Blob and Stream separate. Back in March, we provided some suggestions about using streams in the context of Media Capture and Speech with our submission to the HTML Speech XG [3]. Specifically at that time we said: We propose the addition of a stream type. While this document does not present a detailed design for this type, we assume a Stream is an object that: 1. Has a content type; 2. Has unspecified length; 3. Can generally be used in the same places Blob can be used, for example URL.createObjectURL(). Over the last six months, we have refined our thinking further and would like to submit a proposal for review by the working group that provides that detailed design. We believe that this work is part of the chartered deliverables for File API (and includes XHR support): Streams API - http://html5labs.com/streamsapi/ We recognise that there are a number of different proposals for using stream-like objects elsewhere in the web platform, usually for very specific use cases. What we have tried to define here is a Stream object that is as generic as the Blob object defined in the File API spec. As we started building applications with richer access to devices on the system including files we found the lack of support for an object representing asynchronous data of (initially) unknown size was important. Section 11 of the proposal provides examples of the scenarios we have in mind. To start to address this gap, we have implemented a preview of this mechanism in IE10 Platform Preview 3 behind a vendor prefix (e.g. MSStream) to gain more implementation experience. We look forward to hearing feedback on this proposal, which we've framed mostly as a delta against existing drafts in this working group. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0725.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html [3] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#streams
RE: [File API] Issue 182 about OperationNotAllowed
Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Cheers, Adrian. On Thursday, September 29, 2011 3:28 PM, Arun Ranganathan wrote: On 6/6/11 4:36 PM, Adrian Bateman wrote: On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote: Hi Arun, Jonas, All, The last publication of the File API spec [ED] was last October so it would be good to publish a new Working Draft in w3.org/TR/. Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not appear to identify any open issues, does the spec meet the Last Call Working Draft requirements (as, indicated in previous CfCs for LCWD such as [CfC-LCWD])? If not, what is the schedule and plan to get this spec LC ready? I've added two new issues to tracker [1,2] based on our review of the latest changes to the spec. I think we're getting close to Last Call and it would be good to set a pre-Last Call schedule to tease out any remaining issues. Cheers, Adrian. [1] http://www.w3.org/2008/webapps/track/issues/181 [2] http://www.w3.org/2008/webapps/track/issues/182 Greetings Adrian, I've closed Issue 181, which pertains to a name attribute on exception objects that is now redundant, thanks to WebIDL's evolution for exception interfaces. But I'm not readily able to close Issue 182, which pertains to the OperationNotAllowed exception, which we've added to the specification for reuse across the platform. You cite IndexedDB's reuse of existing exceptions to throw a NOT_ALLOWED_ERR but OperationNowAllowed is for API issues particularly, whereas the other reuses may have more to do with the exception class (within databases, etc.). I updated the comments in Issue 182, in case you want to have the discussion there. But there's a need for a distinct exception that is raised when an operation such as API call order is simply not allowed. To reuse FileException is to tie an API call order question to exceptions typically associated with the underlying file system; that's not what we're trying to do here. The idea was to: 1. Use FileException and FileError uniquely for file errors and 2. To make a clean break with DOMException, which has an untenable list of error codes. Separately, Robin Berjon counsels us NOT to use numerical codes. But I'm not sure what to supplant existing codes with, even if there is overlap. -- A*
RE: We just ran out of time ... [Was: Re: Component Model f2f: Actionable things]
On Tuesday, November 08, 2011 5:37 AM, Robin Berjon wrote: On Nov 3, 2011, at 05:38 , Arthur Barstow wrote: Well, we may get together more frequently than just the annual TPAC meeting week. If folks think that would be useful (e.g. in 6 months), please speak up and we can take it from there. Otherwise, WebApps' next f2f meeting is during the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2. I think that it would be useful for WebApps to get together more frequently (without overdoing it). I'm a big fan of async work in general, but getting people in the same room once in a while helps bang long standing issues into shape and also release whatever pent up tension may have been building. I agree. At the W3C Offline workshop last Saturday there was also a sense from some of the participants that some kind of get together, perhaps in BarCamp style, would be helpful to, at the very least, allow people to share their concerns and get requirements on the table. While we're not chartered to make decisions synchronously, synchronous communication can help to remove misunderstandings. Perhaps in 6 months (twice a year) would be reasonable. On Saturday, November 05, 2011 11:03 AM, James Hawkins wrote: Agreed. What little time we did have was quite productive, and getting to know non-Google WG members outside of a work context was extremely helpful for me. I think getting to know each other better is also helpful in improving how we all work together. Cheers, Adrian.
RE: Identifying Test Spec Editors; deadline Nov 11
On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote: One of the topics discussed this week was to designate a Test Spec Editor(s) for each of our specs. We're supportive of this idea. (BTW, the title of Test Spec Editor is a bit of a straw-man, so proposals for other titles are also welcome.) I wonder if Test Suite Facilitator (or similar) is a better title. We use Facilitator in HTML WG and I think it may be more of a coordination role than a person that does all the editing work of the test suite (that's how it seems to work in HTML at the moment). Cheers, Adrian.
RE: publish new WD of XHR; deadline December 5
On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote: Anne completed his merge XHR and XHR2 merge and the new History section includes information about the merge. As such, this is a Call for Consensus to publish a new WD of XHR using the following ED (not yet pub ready) as the basis: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by December 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I missed much of the discussion on this until now because of the holiday over the weekend in the US. As I said at TPAC, I think continuing only with XHR2 in this exceptional circumstance is the right move provided the group doesn't make a habit of dropping things because there's a newer shiny version. With that in mind, I'd like to see the XHR1 document published as a WG Note. I received a question just this morning asking about the expected behaviour for an XHR implementation in a pre-CORS environment. While not perfect, the XHR1 document is a reasonably good record of the state of implementations prior to CORS and I'm reluctant to lose that information or to have to rely on trying to find a CR publication that doesn't even appear in the history of the new document. Secondly, at least within Microsoft and the web developers that I talk to, the notion of XHR L2 is one that they're familiar with and understood to be distinct from the original. Could we not continue to publish into TR space using the 2 suffix? Thanks, Adrian.
RE: CfC: publish new WD of XHR; deadline December 5
On Thursday, December 01, 2011 5:12 AM, Anne van Kesteren wrote: On Thu, 01 Dec 2011 13:29:37 +0100, Arthur Barstow art.bars...@nokia.com wrote: It appears Adrian is proposing: .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what version of XHR would be used: the 3-Aug-2010 XHR CR, the last ED that was created, some other version? .../TR/XMLHttpRequest2/ be used for Anne's merged version and titled XMLHttpRequest Level 2. Anne, All - WDYT? Adrian - if there is consensus to do something like the above, would you commit to doing the editorial work on the WG Note? (FWIW, I think Adrian's proposal is reasonable and it meets the I Can Live With It Test and if Anne wants the ED to remain version-less, that's OK, provided L2 is added to versions published in /TR/.) It seems totally pointless to me, but we can add even more cruft to the TR/ versions, sure. I should probably also add a disclaimer similar to what http://www.w3.org/TR/html5/ has so it is clear TR/ does not represent the latest version. I don't think it's pointless for the reasons I gave. One of the valuable aspects of the W3C is the traceability that comes from the archive in TR space. We have implementations of XHR L1 that, while not 100%, are mostly conforming deployed with customers. I am happy to help with whatever work is needed to make this happen. I haven't reviewed what errata have been added to the CR document in the editor's draft. If there's nothing significant (and I'd hope there wouldn't be to a CR document) I think we could just publish the CR document with appropriate editing as a Note and be done. It's the CR document I'd like to not leave dangling. Cheers, Adrian.
RE: Add PointerLock and Gamepad APIs to WebApps' charter; deadline December 1
On Thursday, November 24, 2011 5:16 AM, Arthur Barstow wrote: Below, Darin proposes the Pointer Lock [PL] (formerly known as Mouse Lock) spec and the Gamepad [GP] spec be added to the Web Applications WG's charter and not the Web Events WG's charter. This is a Call for Consensus to accept that proposal. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is December 1 and all comments should be sent to public-webapps at w3.org. -AB [PL] http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html [GP] http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html Reviewing the consequences of adopting a new work item not currently in the charter is a significant piece of work for us and one week is insufficient to reach a conclusion. I expect this proposal will be formally reviewed as part of the overall charter review as with the other proposals we discussed at TPAC and that this call for consensus is for including these specs as deliverables on the proposed charter. At the present time Microsoft doesn't have a position for or against working on these specs in WebApps but it seems reasonable to include them for consideration in the proposed new WebApps charter. Cheers, Adrian.
[stream-api] Editor's Draft for Streams API
Following the discussion we had at TPAC [1], we have uploaded our draft as an editor's draft to Mercurial: http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This is just a starting point for discussion and we're looking forward to incorporating feedback as we move forward. We know there are a few things that need to sync with other specs and Feras is working on that. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 On Thursday, September 22, 2011 11:35 AM, I wrote: There has been discussion in this group now and again about the need for stream support as part of the File APIs including recently in the threads about Streaming Blobs [1] and XHR streaming [2]. I've also had several private conversations with members of the WG about the need we see for this kind of stream support. Initially, we thought that supporting a streaming Blob was the correct solution but we ran into a number of issues with this as we investigated further. First of all, people were confused about using the term Blob to represent something of unknown size. Secondly, we received guidance from a number of people to keep the two concepts of Blob and Stream separate. Back in March, we provided some suggestions about using streams in the context of Media Capture and Speech with our submission to the HTML Speech XG [3]. Specifically at that time we said: We propose the addition of a stream type. While this document does not present a detailed design for this type, we assume a Stream is an object that: 1. Has a content type; 2. Has unspecified length; 3. Can generally be used in the same places Blob can be used, for example URL.createObjectURL(). Over the last six months, we have refined our thinking further and would like to submit a proposal for review by the working group that provides that detailed design. We believe that this work is part of the chartered deliverables for File API (and includes XHR support): Streams API - http://html5labs.com/streamsapi/ We recognise that there are a number of different proposals for using stream-like objects elsewhere in the web platform, usually for very specific use cases. What we have tried to define here is a Stream object that is as generic as the Blob object defined in the File API spec. As we started building applications with richer access to devices on the system including files we found the lack of support for an object representing asynchronous data of (initially) unknown size was important. Section 11 of the proposal provides examples of the scenarios we have in mind. To start to address this gap, we have implemented a preview of this mechanism in IE10 Platform Preview 3 behind a vendor prefix (e.g. MSStream) to gain more implementation experience. We look forward to hearing feedback on this proposal, which we've framed mostly as a delta against existing drafts in this working group. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public- webapps/2011JulSep/0725.html [2] http://lists.w3.org/Archives/Public/public- webapps/2011JulSep/0741.html [3] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att- 0001/microsoft-api-draft-final.html#streams
[FileAPI] Blob protocol version - is this needed?
The current spec defines the Blob Protocol Version [1]. Our current implementation doesn't require a protocol version and the way protocol handlers are defined in Internet Explorer does require this. I don't know if this is ever exposed in the web platform. The spec says that this should be returned from XHR in getAllResponseHeaders [2] but I don't think XHR actually returns this string there. Please can someone help point me to where this is required? If it isn't exposed anywhere I think we can remove this section. Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolName [2] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolExamples
[FileAPI] Length of the opaque string for blob URLs
The current spec requires the opaque string in Blob URLs to be at least 36 characters in length [1]. Our implementation doesn't currently use a UUID and the length of the string is shorter than 36 characters. While I have no problem with the recommendation to use UUIDs in the spec, since it isn't a MUST I wonder whether the length requirement needs to be a MUST. Could we relax this requirement? Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#OpaqueStringDiscussion
[FileAPI] Remove readAsBinaryString?
Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
[FileAPI] createObjectURL isReusable proposal
At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
RE: [FileAPI] Length of the opaque string for blob URLs
On Wednesday, December 14, 2011 3:38 AM, Marcos Caceres wrote: On Wednesday, December 14, 2011 at 1:03 AM, Adrian Bateman wrote: The current spec requires the opaque string in Blob URLs to be at least 36 characters in length [1]. Our implementation doesn't currently use a UUID and the length of the string is shorter than 36 characters. While I have no problem with the recommendation to use UUIDs in the spec, since it isn't a MUST I wonder whether the length requirement needs to be a MUST. Could we relax this requirement? Just out of interest, what was the rationale for the minimum of 36 chars? I'm guessing it's because of the length of a typically serialised UUID.
RE: [FileAPI] createObjectURL isReusable proposal
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. I think we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob which is much cleaner I think. (The content attribute would then be set to about:object-url or some such.) I've seen this discussed before. I'm not overly enamoured with this approach. Here are some of the reasons: 1. We have to change these properties to be of type 'any' and it's not obvious what impact that will have. 2. It involves making substantial changes to code flows that source content, which at least for us, would mean a fair amount of code churn. 3. It's not very obvious what the lifetime of the blob should be if it goes out of scope after this happens. We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change to the lifetime management of the Blob URL and was relatively simple (for us) to implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. Cheers, Adrian.
