Re: Delay in File * spec publications in /TR/ [Was: CfC: publish LCWD of File API; deadline March 3]

[Arun Ranganathan]

> On Mar 30, 2012, at 2:25 PM, ext Eric U wrote:
> 
> > On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow
> >  wrote:
> >> Hi All - the publication of the File API LC was delayed because of
> >> some logistical issues for Arun as well as some additional edits
> >> he intends to make.
> >> 
> >> This delay also resulted in Eric's two File * specs not being
> >> published since they have a dependency on the latest File API
> >> spec.
> >> 
> >> Arun - can you please give us at least a rough idea when you
> >> expect the spec to be ready for LC publication?
> >> 
> >> Jonas - as co-Editor of File API, can you help get the File API LC
> >> published?
> >> 
> >> Eric - your File * docs were last published in April 2011 so I
> >> think it would be good to get new versions published in /TR/
> >> soon-ish. OTOH, if they have dependencies on the latest File API,
> >> it may be better to postpone their publication until File API is
> >> published. WDYT?
> > 
> > If it's going to be more than a month to get Arun+Jonas's spec up,
> > we
> > might as well go ahead and publish mine; they've had quite a bit of
> > change.  If it's less than that, let's just do them all together.
> 
> Eric - I haven't received any responses from Arun or Jonas so I will
> contact you off list about getting your two File specs ready for
> publication on /TR/.


Apologies for the delay in getting back to the listserv about changes to File 
API.  Internal logistics have been resolved, and I look forward to making edits 
on the File API specification.  

As Eric points out, it is probably going to be more than 2 weeks till I can 
account for all the necessary edits.  Eric's drafts don't need to be held up 
this timeline, though we should probably keep some things closely in sync., 
especially events, errors, etc.

-- A* 

[Bug 16733] New: Drop 'endings'?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16733

   Summary: Drop 'endings'?
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


File API Writer says about BlobBuilder's endings:

[[
Can we do without endings? Any choice other than "native" can be implemented by
the app author, and most file formats don't care about line endings. "Native"
would be handy for sharing certain types of text files with apps outside the
browser [e.g. Makefiles on a system where make is expecting \n will have issues
if they're written with \r\n]. Is it worth it? Can this be worked around if we
don't supply it?
]]

This bug is about the Blob constructor's 'endings'. What's the motivation for
having it? Can we drop it? In BlobBuilder it only applies for DOMString, but
Blob constructor doesn't say whether it applies for only DOMString or all of
DOMString, ArrayBuffer and Blob.

Authors who want to normalize line endings in their DOMStrings on Windows can
do so manually before passing the string to the Blob constructor, by checking
navigator.platform.substr(0, 3) == 'Win' and then a simple replace().

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16732] New: Use ArrayBufferView instead of ArrayBuffer in Blob constructor

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16732

   Summary: Use ArrayBufferView instead of ArrayBuffer in Blob
constructor
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


XHR.send() was changed to use ArrayBufferView instead of ArrayBuffer because if
you have a sliced view you may want to send that (or here create a blob), but
.buffer represents the whole data, not just the sliced view.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16731] New: Define when "native" ending conversion happens

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16731

   Summary: Define when "native" ending conversion happens
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


The spec should say if the "native" ending conversion is to be done on each
array element separately or after joining them. e.g.:

var b = new Blob(['\r', '\n'], {endings:"native"});

-- 
Configure bugmail: https://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: Shared workers - use .source instead of .ports[0] ?

[Arthur Barstow]

Hi All - I created bug [16730] to capture this question/issue.

The CfC to publish a CR of Workers started on April 4 [CfC], the same 
day Simon posted his question [Head]. Since there were no objections to 
the CfC and a solution to this issue is likely to be backward 
compatible, I intend to move forward with the CR transition request 
using the latest ED of Workers as the basis. If the resolution of this 
bug is substantive (e.g. from the perspective of implementations), that 
will likely require an additional LC->CR cycle. Nevertheless, my 
preference is to not block the CR on this issue. If anyone has any major 
concerns about proceeding this way, please speak up as soon as possible.


-Thanks, AB

[CfC] 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0047.html
[Head] 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0049.html

[16730] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16730

On 4/11/12 1:41 PM, ext Ian Hickson wrote:

I'm fine with making changes here. The following proposals seem to make
the most sense, though I'm sure others could work too:

  1. Leave it as is.

  2. Make the .source attribute be of type (MessagePort or WindowProxy)?
 and add the port to .source, also leaving it in .ports[0].

  3. Make the .source attribute be of type (MessagePort or WindowProxy)?
 and add the port to .source, making .ports null.

  4. Set the .data attribute to the port, leaving it also in .ports[0].

  5. Set the .data attribute to the port, making .ports null.

  6. Use a new event object instead of MessageEvent.

For back-compat, 1, 2, or 4 seem best.

For similarity with posting things to other windows, 2 or 3 seem best.
However, I think the similarity is a bit shallow in practice.

For similarity with how messages are handled elsewhere in Workers and when
using MessagePorts in general, 1 and 4 seem best.

For cleanliness of code, any of 2-6 seem best.

For consistency acros codebases on the Web, 1, 3, 5, or 6 seem best.

If you count each of these considerations as being of equal importance,
then options 1, 2, 3, and 4 all come out equally good.

Right now the only actual implementation argues for 1, I believe.

I think if I were designing the API from the ground up today I would do
either 3 or 6. I think with back-compat concerns I would probably
compromise by going for 2.

Best way to convince me is to ship what you want. :-)

[Bug 16730] New: Shared workers - use .source instead of .ports[0] ?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16730

   Summary: Shared workers - use .source instead of .ports[0] ?
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: art.bars...@nokia.com
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org,
art.bars...@nokia.com


This bug captures Simon Pieters' 4-Apr-2012 to WebApps
.
Several people responded to that thread and on April 11, Hixie replied with
several potential ways to address the issue
.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16729] New: Make endings an enum

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16729

   Summary: Make endings an enum
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


I think it would make sense to make the endings member an enum as follows, to
make invalid values throw TypeError:

enum EndingTypes { "transparent", "native" };
dictionary BlobPropertyBag {

  ...
  EndingTypes endings = "transparent";

};

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16728] New: Blob.type

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16728

   Summary: Blob.type
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


"The ASCII-encoded string in lower case representing the media type of the
Blob"

DOMStrings aren't ASCII-encoded. If type was set with the Blob() constructor,
it isn't necessarily in lowercase, either.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16727] New: Remove "If an invalid key is used or if the dictionary argument is invalid, user agents MUST throw an InvalidStateError."

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16727

   Summary: Remove "If an invalid key is used or if the dictionary
argument is invalid, user agents MUST throw an
InvalidStateError."
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


"If an invalid key is used or if the dictionary argument is invalid, user
agents MUST throw an InvalidStateError."

This is not appropriate; the right behavior is covered by WebIDL. Please remove
this paragraph.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16726] New: Remove quotes in "transparent" and "native" values

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16726

   Summary: Remove quotes in "transparent" and "native" values
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


The spec is inconsistent in whether the quotes are included in the string or
not. The IDL suggests they are not, but the prose suggests they are. Clearly
the intention is to not include them, so the right fix is to remove them from
prose.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16724] New: Blob without arguments underdefined

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16724

   Summary: Blob without arguments underdefined
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


The spec should say what to set the data to (when invoked with no arguments),
what to set the type to (if not specified), what 'endings' should be (if the
second argument is omitted altogether), etc.

Ideally I'd like the spec to have a single algorithm for when the constructor
is invoked, where all values are initialized to the appropriate things, then
the arguments are examined and change the values as appropriate, then a new
Blob object is created with those values set and that is returned. (See
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket
for an example of this style to spec constructors that doesn't leave things
undefined.)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16723] New: Bogus requirement in Blob constructor

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16723

   Summary: Bogus requirement in Blob constructor
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


"A blobParts Array
which MUST take any number of the following types of members, and in any
order:"

This MUST is bogus. WebIDL makes sure the array's elements are of the right
types.

Also, they aren't members, but array elements, per WebIDL terminology.

Suggested replacement:

"A blobParts Array
which takes any number of the following types of array elements, and in any
order:"

(and s/member/array element/ elsewhere as appropriate)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16722] New: Add references to bugzilla from the spec

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16722

   Summary: Add references to bugzilla from the spec
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: ms2...@gmail.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


Currently, there is no reference from the spec to this bugzilla component; a
link to file a bug, and one to see the open bugs, should be added. A
"participate" block like in DOM4
 is one way to do it.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16721] New: Blob constructor with wrong args

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16721

   Summary: Blob constructor with wrong args
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob

"If a type that is not one of DOMString [WebIDL], ArrayBuffer [TypedArrays], or
Blob is used as a blobParts member, the user agent MUST throw an
InvalidStateError."

I think this requirement should be struck. WebIDL should take care of it (it
converts to DOMString).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.