RE: [fileapi] Pull Request on GitHub
> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote: > Sorry about that. Somehow that PR slipped through the cracks. I've commented > on the PR. > > Anybody knows what the deal is with the ipr check? What makes it fail, and if > it fails who is supposed to do what to not make it fail? This happens when someone who is not a recognized (by the tool) member of the WG makes a pull request. Since this looks like only editorial changes, we'll mark it as non-substantive. Cheers, Adrian.
WG Decision on referencing the Image Description (longdesc) extension
The chairs have published details of the Working Group decision on referencing the Image Description (longdesc) extension in HTML. In short, most of the CfC carried without objection but there were some objections related to the longdesc examples. For convenience, the decision text is pasted below but the full text including links is posted at [1]. Thanks to everyone who participated in the CfC discussion. Adrian, on behalf of the WPWG chairs. [1] https://github.com/w3c/WebPlatformWG/blob/gh-pages/decisions/imagedesc-08-2016.md Working Group Decision on referencing the Image Description (longdesc) extension in HTML Question before the working group The HTML 5.1 draft added normative references to the Image Description (longdesc) Recommendation including IDL definitions. The CfC issued on 5 August 2016 proposed: 1. Remove the longdesc attribute from the table of attributes in HTML core. 2. Remove the IDL information for the longdesc attribute from HTML core. 3. Keep the longdesc examples in HTML core. 4. Create a WG Note listing known extension specifications. 5. Include a link to the HTML Extension Specifications Note from HTML core (probably in the index). Consensus There were expressions of support and no objections for #1, #2, #4, and #5. These steps reflect the consensus of the group. Objections There was disagreement on #3 namely whether to keep non-normative examples for longdesc in the specification. In summary, the concerns raised here are: * Some people indicated that the HTML 5.1 spec should not include examples for technology that is not normatively defined in the spec itself. * Some people indicated that non-normative examples necessarily rely on technology that is not defined in the spec, though no examples were cited. * Some people indicated that editors should have editorial freedom over non-normative text including examples. Separately, a concern was raised that whatever decision was taken for longdesc should also apply to other features such as RDFa and the rev attribute. Decision of the Working Group Principles The Working Group has not yet chosen an approach for how to modularise the HTML specification. This topic will be discussed at TPAC 2016. Until this is decided, the chairs intend to implement the following principles: * The Working Group SHOULD NOT incorporate features from HTML Extension Specifications that have independently reached Recommendation status into the main HTML Specification. * The Working Group SHOULD maintain a list of applicable HTML Extension specifications as a Working Group Note. In addition: * The Working Group provides editors the freedom to enhance specifications with non-normative text that improves readability and makes documents easier to understand without seeking approval from the working group. However, members of the Working Group MAY express an opinion on this text and seek consensus to change it. Summary of Arguments In the judgement of the chairs, the strongest argument for not incorporating longdesc in informative examples is that the feature does not exist in the HTML 5.1 specification and isn't necessary for the rest of the example to be valid. It may be true that some examples rely on technology not defined in HTML 5.1 but in general this should only be done when it is necessary for the example to be easily comprehended. In this case, the weakest argument for leaving the informative examples intact was that this is a decision left to the editorial team. While we don't intend to micro-manage the great editorial work contributed by the editors, in this instance the argument to avoid technology defined elsewhere if feasible is more persuasive. By applying the principles above, we must consider whether other parts of the HTML 5.1 draft also incorporate features from other W3C Recommendations. The chairs agree that the RDFa examples are part of a Recommendation and must also be removed. The rev attribute was previously described in HTML 5.0 and the HTML 5.1 draft defines this content attribute in a more formal way. The rev attribute does not need to be removed. Decision The Web Platform Working Group adopts parts #1, #2, #4, and #5 of the CfC proposal. Further, the Web Platform Working Group rejects #3 and adopts the decision to remove longdesc from the examples in HTML 5.1. This reverts the document to the same state as HTML 5.0 for this issue. The Web Platform Working Group will also apply this decision to RDFa and will remove the RDFa examples. Next steps The chairs will ask the editors to remove the longdesc content that was added through PR #441 and PR #449 and the similar RDFa content. The chairs and Team will work with the editors will to create a Working Group Note listing the applicable HTML extension specifications. Appealing this Decision If anyone feels they have not received due process, or that their concerns have not being duly considered in the course of
RE: Art steps down - thank you for everything
On Thursday, January 28, 2016 7:46 AM, Chaals McCathie Nevile wrote: > Now we are three co-chairs, we will work between us to fill Art's shoes. > It won't be easy. > > Thanks Art for everything you've done for the group for so long. Thanks Art. You were there from the first day I showed up at W3C with a light but steady hand on the tiller. Thank you for all your help. We won't be able to fill Art's shoes but we'll try to keep the group moving along with a light touch while still closing issues and making progress. Cheers, Adrian.
RE: Exception APIs feedback
On Tuesday, April 29, 2014 5:46 AM, Anne van Kesteren wrote: Both http://www.w3.org/2011/tracking-protection/drafts/tracking- dnt.html#exceptions-javascript-api and http://www.w3.org/2011/tracking-protection/drafts/tracking- dnt.html#exceptions-ww-javascript-api are inadequate. They need to allow for an asynchronous permission check. In other words, return a promise. The design of the API was explicitly chosen to not use a promise pattern. Given the expectation that few browsers would provide a UI and that exceptions could be revoked soon after the UI prompt it is incumbent on sites to check what exception status exists using the query methods. This API does not seem ready at all. Are there any implementations of it? Yes. It is implemented in IE11.
RE: Passsword managers and autocomplete='off'
On Thursday, December 12, 2013 1:57 PM, Jonas Sicking wrote: On Thu, Dec 12, 2013 at 1:45 PM, Joel Weinberger j...@chromium.org wrote: But it would suck if the result is that they create their own form fields using divs and/or contenteditable. That's true, although some things like that are already pretty prevalent so we've come up with decent heuristics for detecting them. In the end, though, they always can try obfuscation, but we think that this will, in fact, benefit their users. Whether it benefits users or not is unfortunately less relevant than whether websites thinks that it benefits users. Since if they don't think it does, we'll end up in an escalating war of browsers and websites working around each other. Reaching out to banks might be good. Is that something you've looked at? Yes, we're definitely doing that. From our perspective, we'd be happy with making the switch today, but we're trying to be good netizens and (a) give fair warning, and (b) make sure we're not missing something critical. I'd be very interested in hearing what feedback you get. If we knew that banks were onboard with whatever is proposed, that would definitely make us more comfortable with deploying the same solution. We agree with this approach. In IE11, we decided to stop supporting [1] the autocomplete attribute with input type=password in order that we could offer password management for more authentication forms. We never store passwords without the user choosing to allow this when prompted for a specific site. We haven't heard any significant negative feedback so far. Cheers, Adrian. [1] http://msdn.microsoft.com/en-us/library/ie/ms533486
RE: CfC: publish FPWD of Shadow DOM; deadline May 9
Microsoft supports this CfC. On Wednesday, May 02, 2012 1:20 PM, Arthur Barstow wrote: As discussed during WebApps' May 1 f2f meeting [2], the Shadow DOM spec is ready for a First Public Working Draft (FPWD) publication and this a Call for Consensus (CfC) to do so: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html 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. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is May 9. Please send all comments to: public-webapps@w3.org -Art Barstow [1] http://www.w3.org/2012/05/01-webapps-minutes.html#item03
RE: CfC: to stop work on XBL2; deadline May 8
Microsoft supports this call. On Tuesday, May 1, 2012 9:26 PM, Arthur Barstow wrote: During WebApps' May 1 discussion about Web Components, a proposal was made ([1],[2]) to stop work on the XBL2 spec and this is a Call for Consensus to do do. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by May 8 at the latest. Positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. If this CfC passes, the spec will be republished as a WG Note (as was done with other specs WebApps has stopped such as Web SQL Database). -Thanks, AB [1] http://www.w3.org/2012/05/01-webapps-minutes.html#item03 [2] http://www.w3.org/2012/05/01-webapps-minutes.html#item04 Original Message Subject: ACTION-658: Start CfC to create a WG Note for XBL2 (and Chaals will do the work) (Web Applications Working Group) Date: Tue, 1 May 2012 18:22:25 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-658: Start CfC to create a WG Note for XBL2 (and Chaals will do the work) (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/658 On: Arthur Barstow Due: 2012-05-08 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
RE: [FileAPI] Blob protocol version - is this needed?
On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote: Greetings Adrian, Sorry for the delay in responding to this email. Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It isn't returned in getAllResponseHeaders. BLV 's purpose was in case the protocol changes, and to differentiate between versions. But the protocol is internally consumed within the UA. I can remove it. Thanks - I think that would be the right move. I don't think there's a way to test it (and as I mentioned in my previous note our implementation doesn't have it). Cheers, Adrian.
RE: CfC: to add Speech API to Charter; deadline January 24
Microsoft is open to adding this to the WebApps charter. We certainly want to see work on a speech API for user agents proceed at W3C. Our priorities for the API are 1) a procedural (JavaScript) API and 2) a declarative syntax for speech recognition and text-to-speech in HTML. We think WebApps would be a good venue to bring speech to the attention of members who wouldn't normally participate in this area. On the other hand we recognise that there may be some members who are interested in moving speech forward but who might not be willing to make IPR commitments for other specifications that WebApps works on. If that is the case then we'd rather have them involved in a separate working group than not benefit from their contributions. Cheers, Adrian. On Friday, January 20, 2012 12:58 PM, Arthur Barstow wrote: The deadline for comments is extended to January *24*. On 1/20/12 6:55 AM, ext Arthur Barstow wrote: The deadline for comments is extended to January. Andrian, Maciej - I would appreciate it you would please provide some feedback on this CfC. On 1/12/12 7:31 AM, ext Arthur Barstow wrote: Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public-webapps at w3.org. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.ht ml [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-169 6/speechapi.html
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.
RE: [FileAPI] createObjectURL isReusable proposal
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com 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.) The problem is that we have tons of APIs that deal with URLs in the form of strings. Not least the CSSOM which uses a lot of string concatenation. So we'd have to sign up for a very big task of changing all of these APIs so that they work with objects instead of strings. Speccing and getting that implemented will take a considerable amount of time. There's also things like .innerHTML which people often prefer over using the direct DOM API. Some of this is likely due to the pain that the DOM-API is, but I suspect even with a perfect DOM API we'd still see a lot of string usage due to it's ease of use. So I'm not convinced that the value/cost ratio of this proposed solution is high enough. I agree - I forgot to mention the CSSOM issue in my previous reply but it is something we've thought about too. Adrian.
RE: [FileAPI] createObjectURL isReusable proposal
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote: 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. I'd expect making this fully interoperable to be a complex problem. It makes fetch order significant, where it currently isn't. For example, if two images have their @src attribute set to a URL one after the other, what guarantees which one succeeds (presumably the first) and which fails (due to the first releasing the URL)? The order in which synchronous sections after await a stable state are run isn't specified. Combining different APIs which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource selection algorithm) would compound the problem. Another possible problem, depending on where the blob release takes place: if the UA doesn't support images, update the image data for HTMLImageElement terminates at step 4; it would need to be careful to still release the blob URL when terminating before the fetch. This would probably have effects across a lot of specs, and couldn't be neatly tucked away in one place (such as inside the resource fetch algorithm); and it might force every API that performs fetches to worry about creating race conditions with other APIs. Assigning the blob directly would still affect various specs, but it would be less likely to lead to blob leakage and subtle, possibly racy interop failures. I don't think we need interop for race conditions. Trying to use a one-time URL twice is supposed to go wrong and I don't think it necessarily has to go wrong in exactly the same way in all browsers. You might have the same problem based on when you call revokeObjectURL in applications today. 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: 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.
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: 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: [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*
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: 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
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: 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.
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: 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 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: [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: [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: [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: [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: [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: 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: [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: 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: [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: [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: [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.
[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: 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,
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: [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 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: [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 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.
[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: 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/
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 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: 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: 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: 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: 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: 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.
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: 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.
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.
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: 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
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: [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: [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: 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: 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: 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: 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: 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
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: [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.
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.
