Re: PSA: publish WD of "WebIDL Level 1"

[Anne van Kesteren]

On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa  wrote:
> Let's say we implement some feature based on Web IDL published as of today.  
> I'm going to refer that in my source code commit message.  Future readers of 
> my code has no idea what I was implementing when they look at my commit 
> message in five years if it refers to the living standard that changes over 
> time.

Apart from what Domenic said, IDs should remain stable over time and
other than features getting expanded, they need to remain backwards
compatible, just as your code base. (It also seems like useful
information to know what you've implemented has been refactored or
changed in some way in the corresponding standard, so you can take
steps to update your code.)


-- 
https://annevankesteren.nl/

RE: PSA: publish WD of "WebIDL Level 1"

[Domenic Denicola]

From: Ryosuke Niwa [mailto:rn...@apple.com]

> For our internal documentation purposes, I'd refer having a perm link to a
> document that never changes.
> 
> Let's say we implement some feature based on Web IDL published as of
> today.  I'm going to refer that in my source code commit message.  Future
> readers of my code has no idea what I was implementing when they look at
> my commit message in five years if it refers to the living standard that
> changes over time.

I agree this is an important use case. Fortunately it is covered by commit 
snapshot URLs. E.g. 
https://rawgit.com/heycam/webidl/a90316a16f639aaa3531208fc0451a1b79a35a7d/index.html

This is better than expecting that the one time a snapshot happens ("v1"), it 
also aligns with what you're implementing at the time.

(BTW: for streams I have made this concept first-class; at 
https://streams.spec.whatwg.org/ you can click the "Snapshot as of this commit" 
link to get 
https://streams.spec.whatwg.org/commit-snapshots/5bd0ab1af09153fd72745516dadc27103e84043c/.)

Re: PSA: publish WD of "WebIDL Level 1"

[Ryosuke Niwa]

> On Aug 7, 2015, at 9:27 AM, Anne van Kesteren  wrote:
> 
> On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead
>  wrote:
>> This is, at a minimum, incremental goodness. It's better than leaving the 
>> prior L1 published document around--which already tripped up a few folks on 
>> my team recently. I strongly +1 it.
> 
> If your team looks at the newer L1 they will also trip themselves up.
> Anything but https://heycam.github.io/webidl/ is problematic.

For our internal documentation purposes, I'd refer having a perm link to a 
document that never changes.

Let's say we implement some feature based on Web IDL published as of today.  
I'm going to refer that in my source code commit message.  Future readers of my 
code has no idea what I was implementing when they look at my commit message in 
five years if it refers to the living standard that changes over time.

- R. Niwa

[Bug 29105] MediaStream Recording API: Consider not using BlobEvent, using Blob and FileReader instead

[bugzilla]

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

Miguel Casas-Sanchez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Miguel Casas-Sanchez  ---
Dup'ed in https://github.com/w3c/mediacapture-record/issues/17

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29102] MediaStream Recording API: remove RecordingErrorNameEnum and use DomException instead

[bugzilla]

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

Miguel Casas-Sanchez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29103] MediaStream Recording API: MediaRecorderErrorEvent is a NoInterfaceObject, consider removing

[bugzilla]

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

Miguel Casas-Sanchez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29104] BlobEvent is defined in both MediaStream Recorder and MediaStream ImageCapture, consider factoring them out.

[bugzilla]

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

Miguel Casas-Sanchez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29105] New: MediaStream Recording API: Consider not using BlobEvent, using Blob and FileReader instead

[bugzilla]

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

Bug ID: 29105
   Summary: MediaStream Recording API: Consider not using
BlobEvent, using Blob and FileReader instead
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Streams API
  Assignee: tyosh...@google.com
  Reporter: mca...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
  Target Milestone: ---

MS Recording API defines a certain BlobEvent as a way to
read the recorded data [1]. 

Since BlobEvent is just a convenience wrapper around a 
Blob [2], consider using the latter for extracting recorded
data.

[1] http://www.w3.org/TR/mediastream-recording/#blob-event
[2] http://www.w3.org/TR/FileAPI/#blob

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29104] New: BlobEvent is defined in both MediaStream Recorder and MediaStream ImageCapture, consider factoring them out.

[bugzilla]

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

Bug ID: 29104
   Summary: BlobEvent is defined in both MediaStream Recorder and
MediaStream ImageCapture, consider factoring them out.
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Streams API
  Assignee: tyosh...@google.com
  Reporter: mca...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
  Target Milestone: ---

In [1] and [2], respectively.

[1] http://www.w3.org/TR/mediastream-recording/#blob-event
[2] http://www.w3.org/TR/image-capture/#blobevent

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29103] New: MediaStream Recording API: MediaRecorderErrorEvent is a NoInterfaceObject, consider removing

[bugzilla]

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

Bug ID: 29103
   Summary: MediaStream Recording API: MediaRecorderErrorEvent is
a NoInterfaceObject, consider removing
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Streams API
  Assignee: tyosh...@google.com
  Reporter: mca...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
  Target Milestone: ---

MediaRecorderErrorEvent [1] idl says it's  NoInterfaceObject,
consider removing it.

[1] http://www.w3.org/TR/mediastream-recording/#MediaRecorderErrorEvent

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 29102] New: MediaStream Recording API: remove RecordingErrorNameEnum and use DomException instead

[bugzilla]

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

Bug ID: 29102
   Summary: MediaStream Recording API: remove
RecordingErrorNameEnum and use DomException instead
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Streams API
  Assignee: tyosh...@google.com
  Reporter: mca...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
  Target Milestone: ---

The said RecordingErrorNameEnum [1] should not exist stand alone,
since it partially overlaps DomException [2], concretely 
INVALID_STATE_ERR and SECURITY_ERR. Reuse DomException.


[1] http://www.w3.org/TR/mediastream-recording/#MediaRecorderErrorEvent
[2] http://www.w3.org/wiki/DOM/domcore/DOMException

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: PSA: publish WD of "WebIDL Level 1"

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Yves,

On 08/31/2015 03:28 PM, Yves Lafon wrote:
> In fact, I would prefer to have the editors’ copy published as 
> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version 
> (aka, what is implemented, not what has to be implemented).
> 

Who do you propose will construct such a "what is implemented"
specification, and what useful work would you have them drop for it?

Thanks
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV5JkbAAoJEOXgvIL+s8n27aQH/jCaZRS6ONmC1aklZACK5Iep
NV5VSxq1H2aHv6rdRiBNygeGzEiwENZUnIzv0r0ebQMCRCvhwXqbm+srV9FlFNdb
dJ7c41cXNHIk4D1+18vYvK4AenqkHE5zozm4LqoZ8SL+YLRFYyIhpXOsV34R5DnP
wjyLcEbcFgWmYK2TXTNphhTXEmebM89o4vmGkrKPdYqAwWaWNJz5L6hMZARH7lWq
eYL0iwo9BQbIfR0gLIpuARvS2oOS0Y7/8gNkMuEQ4h9UHa+hcvsOL0JWI6Zz2vTM
ZNO3nAE1h5In6DFXmK3ZkIlOpIGgsVsK7KmiIKlvZAOZ9NXui851uYA9j2YQQ3U=
=ixCO
-END PGP SIGNATURE-

Re: PSA: publish WD of "WebIDL Level 1"

[Yves Lafon]

> On 07 Aug 2015, at 14:45, Arthur Barstow  wrote:
> 
> On 8/4/15 2:21 PM, Tab Atkins Jr. wrote:
>> On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow  
>> wrote:
>>> Hi All,
>>> 
>>> This is heads-up re the intent to publish a Working Draft of "WebIDL Level
>>> 1" (on or around August 4) using Yves' document as the basis and a new
>>> "shortname" of "WebIDL-1":
>>> 
>>> 
>>> 
>>> There is an open question about what should happen with TR/WebIDL/ (which
>>> now is the 2012 Candidate Recommendation). One option is to serve it as
>>> WebIDL-1. Another option is to replace it with the latest version of
>>> Cameron's Editor's Draft. A third option is to make it some type of "landing
>>> page" the user can use to load the various versions. Feedback on these
>>> options is welcome and the default (if there are no non-resolvable issues)
>>> is to go with option #2 (Yves' preference).
>> The CSSWG always points the non-leveled url to the latest spec.
> 
> This is also what PLH recommended be done and that seems reasonable to me. 
> Thus:
> 
> TR/WebIDL/ -> TR/WebIDL-2/
> TR/WebIDL-1/
> TR/WebIDL-2/
> 
> The L2 version (by Cameron and Boris [L2]) has not been published as a TR and 
> if there no objections to proceeding as above, I will start working on making 
> this all happen.
> 
In fact, I would prefer to have the editors’ copy published as TR/WebIDL/, and 
let -1 -2 … -n be pointers to the stable version (aka, what is implemented, not 
what has to be implemented).

> -Thanks, AB
> 
> [L2] 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves