RE: [fileapi] Pull Request on GitHub

2016-08-17 Thread Adrian Bateman
> 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

2016-08-17 Thread Adrian Bateman
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

2016-01-28 Thread Adrian Bateman
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

2014-04-29 Thread Adrian Bateman
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'

2014-01-03 Thread Adrian Bateman
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

2012-05-06 Thread Adrian Bateman
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

2012-05-05 Thread Adrian Bateman
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?

2012-02-02 Thread Adrian Bateman
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: Obsolescence notices on old specifications, again

2012-01-27 Thread Adrian Bateman
I will wait to see the proposed text but in the meantime point out that 
Microsoft has regulatory obligations that require us to direct customers to 
these specifications until such time as there is a completed Recommendation 
that succeeds them. As a consequence we want to make sure these customers 
recognise that these are the most up-to-date completed specifications from W3C 
and are not confused by such a notice.

Cheers,

Adrian.

On Wednesday, January 25, 2012 2:31 PM, Arthur Barstow wrote:
 Hi All - I just chatted with Ms2ger in IRC about his proposal [1]. 
 Ms2ger will submit proposed text to the list so we should probably
 hold off on additional comments until we get that proposal.

 (I agree rescinding is not what we want to do for these specs.)

 -AB

 [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0245.html




RE: CfC: to add Speech API to Charter; deadline January 24

2012-01-24 Thread Adrian Bateman
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

2011-12-14 Thread Adrian Bateman
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

2011-12-14 Thread Adrian Bateman
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

2011-12-14 Thread Adrian Bateman
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

2011-12-14 Thread Adrian Bateman
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

2011-12-13 Thread Adrian Bateman
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?

2011-12-13 Thread Adrian Bateman
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

2011-12-13 Thread Adrian Bateman
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?

2011-12-13 Thread Adrian Bateman
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

2011-12-13 Thread Adrian Bateman
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

2011-12-01 Thread Adrian Bateman
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

2011-12-01 Thread Adrian Bateman
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

2011-11-30 Thread Adrian Bateman
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]

2011-11-11 Thread Adrian Bateman
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

2011-11-11 Thread Adrian Bateman
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

2011-09-30 Thread Adrian Bateman
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

2011-09-22 Thread Adrian Bateman
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

2011-09-20 Thread Adrian Bateman
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

2011-09-13 Thread Adrian Bateman
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

2011-09-08 Thread Adrian Bateman
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

2011-08-16 Thread Adrian Bateman
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]

2011-08-16 Thread Adrian Bateman
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?

2011-08-12 Thread Adrian Bateman
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

2011-08-02 Thread Adrian Bateman
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)

2011-07-25 Thread Adrian Bateman
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)

2011-07-21 Thread Adrian Bateman
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)

2011-07-21 Thread Adrian Bateman
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

2011-07-18 Thread Adrian Bateman
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

2011-07-18 Thread Adrian Bateman
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

2011-07-11 Thread Adrian Bateman
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

2011-07-11 Thread Adrian Bateman
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

2011-07-08 Thread Adrian Bateman
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)

2011-07-08 Thread Adrian Bateman
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

2011-07-07 Thread Adrian Bateman
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

2011-07-07 Thread Adrian Bateman
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

2011-07-07 Thread Adrian Bateman
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

2011-07-06 Thread Adrian Bateman
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

2011-07-06 Thread Adrian Bateman
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

2011-06-27 Thread Adrian Bateman
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

2011-06-10 Thread Adrian Bateman
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

2011-06-08 Thread Adrian Bateman
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

2011-06-07 Thread Adrian Bateman
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote:
 On Tue, 7 Jun 2011, Adrian Bateman wrote:
  We have removed onerror from our implementation since the previous 
  change and it's frustrating trying track against the spec with 
  unexpected updates.

 That's the cost of being on the bleeding edge. It's very likely that it 
 will change again. Until we have implementation and authoring experience, 
 we will almost certainly continue to update the specification to address 
 new problems and use cases. If you want to implement things that don't 
 change, then wait til someone else has implemented it and shipped it. 
 Being on the bleeding edge means you are providing the feedback that 
 affects the specification's development.

I'm just asking for a little transparency here: as far as I can see there
were no bugs filed or public e-mail discussion on this nor was there any
explanation in the check-in to change the spec. We understand that things
change but we're hoping that we're getting close to Last Call and we'd
like an opportunity to participate in the discussion before things show
up unexpectedly at this point.

Thanks,

Adrian.



RE: Publishing an update of File API spec

2011-06-06 Thread Adrian Bateman
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



[websockets] Binary support changes

2011-05-27 Thread Adrian Bateman
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

2011-05-27 Thread Adrian Bateman
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

2011-05-27 Thread Adrian Bateman
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()

2011-05-27 Thread Adrian Bateman
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

2011-04-20 Thread Adrian Bateman
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

2011-04-18 Thread Adrian Bateman
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

2011-04-18 Thread Adrian Bateman
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

2011-04-15 Thread Adrian Bateman
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

2011-04-15 Thread Adrian Bateman
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

2011-04-11 Thread Adrian Bateman
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

2011-04-11 Thread Adrian Bateman
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

2011-04-11 Thread Adrian Bateman
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?

2011-04-05 Thread Adrian Bateman
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

2011-03-31 Thread Adrian Bateman
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

2011-03-28 Thread Adrian Bateman
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

2011-03-09 Thread Adrian Bateman
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

2011-03-09 Thread Adrian Bateman
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

2011-03-09 Thread Adrian Bateman
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

2011-02-28 Thread Adrian Bateman
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

2011-02-24 Thread Adrian Bateman
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)

2011-02-24 Thread Adrian Bateman
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

2011-02-24 Thread Adrian Bateman
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

2010-11-29 Thread Adrian Bateman
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

2010-11-16 Thread Adrian Bateman
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

2010-11-12 Thread Adrian Bateman
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

2010-11-09 Thread Adrian Bateman
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: to publish Web SQL Database as a Working Group Note; deadline November 13

2010-11-09 Thread Adrian Bateman
Microsoft supports publication as a Working Group Note.

On Saturday, November 06, 2010 5:35 PM, Arthur Barstow wrote:
 During WebApps's November 1 gathering, participants discussed the Web
 SQL Database spec:
 
   http://www.w3.org/2010/11/01-webapps-minutes.html#item09
[...]
 As such, participants in the discussions suggested the spec be
 published as a Working Group Note and this is Call for Consensus to
 do.
 
 *Note Well: by publishing a Working Group Note, the group sends a
 signal to the community that work on this spec has ended* as described
 in the Process Document:
 
   http://www.w3.org/2005/10/Process-20051014/tr.html#q75
 
 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.


RE: Blob/File naming

2010-09-07 Thread Adrian Bateman
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

2010-08-31 Thread Adrian Bateman
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

2010-07-13 Thread Adrian Bateman
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

2010-07-12 Thread Adrian Bateman
On Sunday, July 11, 2010 10:40 PM, David Levin wrote:
 On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman adria...@microsoft.com
 wrote:
 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.
 
 Specifying the format of contents of the url is simply an
 overspecification. Saying User Agents that wish to include data such as
 origin should do so by encoding it in an opaque manner. is ambiguious.
 As soon as anyone publishes the format (which would be trivial to do
 given chromium's open source), the format would no longer be opaque.

Of course and I wasn't writing spec text merely raising the idea. Feel free
as always to propose some text. I think there's a clear difference between
going to find the chromium source and figuring out how to decode the origin
and seeing origin=blah in the string.

 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.
 
 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.

 This does create something of a race condition. If I have a blob
 representing an image where I set the src of an img element and then
 let the blob go out of scope might it be collected before the img loads
 the resource? We think we'll have to include some mechanism to ensure
 that
 the blob and URL doesn't get collected before pending network requests
 have been made.
 
 This does impose an additional burden on the web developer: if they later
 want to copy the source URL from one img to another then this will only
 work if they also kept the blob in scope somewhere.
 
 What do you think?
 
 Cheers,
 
 Adrian.
 
 [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
 




RE: Lifetime of Blob URL

2010-07-12 Thread Adrian Bateman
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

2010-07-12 Thread Adrian Bateman
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

2010-07-11 Thread Adrian Bateman
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

2010-06-22 Thread Adrian Bateman
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

2010-06-22 Thread Adrian Bateman
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

2010-06-22 Thread Adrian Bateman
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

2010-06-11 Thread Adrian Bateman
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 and blob url schemes

2010-06-11 Thread Adrian Bateman
On Friday, June 11, 2010 7:22 AM, Robin Berjon wrote:
 On Jun 11, 2010, at 15:43 , Adrian Bateman wrote:
  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.
 
 I'd like to make sure that I follow. Without putting words into your mouth,
 are you suggesting that if I obtain such a pointer from a file, I would get
 file-blob:DEADBEEF but if I got it from a capture it would be capture-
 blob:C00lDBABE?

That might be one approach. I wondered whether the proposal here was a single 
unifying scheme for all future uses of Blob without necessarily knowing whether 
that would work or whether each spec that consumes the Blob interface could 
express an approach (which could be the same as the File one).

 There are several reasons why I'm not in favour of that:
 
   - it exposes too much of the underlying implementation, presumably it's not
 the end of the world to have a single object proxying for various providers
   - it introduces a debauchery of new schemes, all of which then have to be
 not only specified by registered
   - more importantly: it's none of the author's business where I'm giving him
 my picture from. If he's asking to use capture but I tell my UA to override
 that and use a file instead, the script should have no way of finding out.

These are good reasons and I'm really just thinking out loud. I've seen some 
discussions about how live webcam capture might use this interface to provide a 
URL for the video feed that you could potentially assign to a video src 
attribute. I'm not sure if this is just an abuse of something that's not really 
a Blob but might the script want to be able to check if it's getting a video? 
Perhaps the URL could have a content type in a similar fashion to data:.

Cheers,

Adrian.



RE: Updates to File API

2010-06-11 Thread Adrian Bateman
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)

2010-05-26 Thread Adrian Bateman
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)

2010-05-24 Thread Adrian Bateman
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

2010-01-20 Thread Adrian Bateman
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

2009-12-22 Thread Adrian Bateman
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

2009-12-21 Thread Adrian Bateman
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

2009-12-21 Thread Adrian Bateman
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

2009-12-15 Thread Adrian Bateman
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

2009-11-20 Thread Adrian Bateman
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



  1   2   >