Re: Mutation events replacement

[Adam Klein]

On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking  wrote:
> On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay  wrote:
>> On 07/21/2011 06:01 PM, Boris Zbarsky wrote:
>>>
>>> On 7/21/11 5:08 AM, Dave Raggett wrote:

 Thanks for the explanation. Apps would need a way to disable
 notifications during such animation sequences, and would be able to find
 another means to serialize the animation (at a higher level).
>>>
>>> I'm not sure I trust apps to do that, which is why I think the default
>>> behavior should be that they just don't get the information.
>>>
 This raises the question is unregistering and re-regtistering a mutation
 notification handler cheap or do we need an alternative mechanism for
 temporarily suspending notifications?
>>>
>>> Olli is better able than I to answer this for Gecko.
>>
>> In the current WIP patch for mutation event replacement registering and
>> unregistering listeners is cheap, and if there are no listeners,
>> performance isn't affected at all.
>> This is with the sync approach.
>>
>> If async approach is taken, listener handling becomes significantly
>> more complicated. What if the listener is added after the mutation has
>> happened, should it be called? If not, then we need to keep a list of
>> changes for all the listeners separately.
>
> Hmm.. the most trivial implementation is to keep different lists for
> different listeners no matter what.
>
> However maybe it's worth allowing listeners to be able to share
> mutation objects? Is that what you were thinking? That might be good
> for performance since it'll create fewer objects, but it'll also add
> more complexity since it requires more bookkeeping.
>
> Though note that the list of mutation objects will have to be
> per-listener no matter what (i.e. both in the mostly-sync and the
> almost-async suggestions) since different listeners will be observing
> different parts of the tree and thus will see different set of
> mutations.
>
> The simplest solution that I can think of is to say that the
> addMutationObserver function doesn't take effect until at the end of
> the task. So any listener registered during a task won't get
> notifications until at the end of the following task.
>
> There are other solutions that we could use, but they seem much more
> complex and so I'd rather avoid them unless there's a good reason to.

This is only complex because you're coalescing the mutations, right?
In Rafael's original proposal, each mutation would result in a single
immutable mutation record, so the semantics would be to "deliver" (by
appending to a queue associated with each observer) a mutation record
to any currently-registered observers.

Or is there some other concern with beginning notifications partway
through a task?

- Adam

Re: Mutation events replacement

[Jonas Sicking]

On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay  wrote:
> On 07/21/2011 06:01 PM, Boris Zbarsky wrote:
>>
>> On 7/21/11 5:08 AM, Dave Raggett wrote:
>>>
>>> Thanks for the explanation. Apps would need a way to disable
>>> notifications during such animation sequences, and would be able to find
>>> another means to serialize the animation (at a higher level).
>>
>> I'm not sure I trust apps to do that, which is why I think the default
>> behavior should be that they just don't get the information.
>>
>>> This raises the question is unregistering and re-regtistering a mutation
>>> notification handler cheap or do we need an alternative mechanism for
>>> temporarily suspending notifications?
>>
>> Olli is better able than I to answer this for Gecko.
>
> In the current WIP patch for mutation event replacement registering and
> unregistering listeners is cheap, and if there are no listeners,
> performance isn't affected at all.
> This is with the sync approach.
>
> If async approach is taken, listener handling becomes significantly
> more complicated. What if the listener is added after the mutation has
> happened, should it be called? If not, then we need to keep a list of
> changes for all the listeners separately.

Hmm.. the most trivial implementation is to keep different lists for
different listeners no matter what.

However maybe it's worth allowing listeners to be able to share
mutation objects? Is that what you were thinking? That might be good
for performance since it'll create fewer objects, but it'll also add
more complexity since it requires more bookkeeping.

Though note that the list of mutation objects will have to be
per-listener no matter what (i.e. both in the mostly-sync and the
almost-async suggestions) since different listeners will be observing
different parts of the tree and thus will see different set of
mutations.

The simplest solution that I can think of is to say that the
addMutationObserver function doesn't take effect until at the end of
the task. So any listener registered during a task won't get
notifications until at the end of the following task.

There are other solutions that we could use, but they seem much more
complex and so I'd rather avoid them unless there's a good reason to.

/ Jonas

RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Ian Hickson]

On Thu, 21 Jul 2011, Adrian Bateman wrote:
> 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?

Content-Type is one big one. It's de-facto "optional" status (mostly 
driven by IE's sniffing behaviour) has had huge security implications, has 
resulted in complicated UA behaviours now being required, has resulted in 
complicated semantics in HTML with respect to when types are honoured and 
when they are not, etc.


> It seems to me that HTTP has been wildly successful and its 
> extensibility is a large part of that.

HTTP has been successful despite being poorly specified, not because of 
it. (Same with HTML.)


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

If the IETF won't do the job right, we have to.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Ian Hickson]

On Thu, 21 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote:
> 
> I understand this point of view. That said, there is a lot of 
> disagreement in the IETF WG about deflate-stream. The extension 
> basically breaks all other extensions, framing, etc. It's a bit of a 
> mess and a lot of us want to just yank it out entirely. There was a much 
> better proposal by yoshino-san (deflate-frame) that basically did 
> compression but still properly framed the compressed result. I think 
> that at least in Chrome we are hoping deflate-frame will take off. That 
> will be in a separate document though as the current protocol doc is in 
> last call, and you are undoubtedly familiar with the logistical 
> considerations of such things.

I've been assuming that the Web Socket protocol spec was what UAs wanted 
to implement. If it's not, then that's a bigger problem.

I don't mind if we turn specific extensions on or off. I just don't think 
it should be optional. If UAs do not want to implement what the protocol 
spec says, I'm equally happy for the API spec to just disallow that 
extension.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Mutation events replacement

[Boris Zbarsky]

On 7/21/11 4:15 PM, Aryeh Gregor wrote:

I can say that it's very common and critical for editors.


I'd really like numbers.  Having looked at the Gecko editor code in the 
past, I don't share your assurance that this is how it works


That said, if you point to a workload, I (or anyone else; it's open 
source!) can probably generate some numbers by instrumenting the Gecko 
DOM.  But I need a workload.


-Boris

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[イアンフェッティ]

Ian,

I understand this point of view. That said, there is a lot of disagreement
in the IETF WG about deflate-stream. The extension basically breaks all
other extensions, framing, etc. It's a bit of a mess and a lot of us want to
just yank it out entirely. There was a much better proposal by yoshino-san
(deflate-frame) that basically did compression but still properly framed the
compressed result. I think that at least in Chrome we are hoping
deflate-frame will take off. That will be in a separate document though as
the current protocol doc is in last call, and you are undoubtedly familiar
with the logistical considerations of such things.

-Ian

On Thu, Jul 21, 2011 at 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.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Re: Mutation events replacement

[Aryeh Gregor]

On Wed, Jul 20, 2011 at 3:11 PM, Ryosuke Niwa  wrote:
> But internally, a node movement is a removal then an insertion.  There's
> always possibility that a node gets removed then inserted again after
> mutation observers are invoked.  Also, what happens if a function removed a
> bunch of nodes and then inserted back one of them?

I'm suggesting that we change insertNode()/appendChild()/etc. so that
they're *not* internally a removal then an insertion: they're
internally atomic.  If you call foo.removeChild(bar);
foo.appendChild(bar) then that would be a remove/insert no matter
what.  But if you call foo.appendChild(bar) and bar has a parent and
bar is not the last child of foo, that would be a move.

Yes, this causes problems as long as mutation events exist.  But when
mutation event handlers modify the DOM, behavior is undefined and is
totally inconsistent between browsers in practice, so I don't think
it's a big deal.  Just do whatever's convenient and leave the behavior
inconsistent in this case like in others.  We don't need to
standardize behavior here unless we're going to standardize behavior
in all other cases where DOM mutation listeners mutate the DOM, which
we aren't.

On Wed, Jul 20, 2011 at 10:17 PM, Boris Zbarsky  wrote:
> What I do have a strong opinion on is that it would be good to have some
> data on how common "move" operations are compared to "remove" and "insert"
> on the web.  Then we'll at least know how common or edge-case the situation
> is and hence how much effort we should spend on optimizing for it...

I can say that it's very common and critical for editors.  Tons of
what you're doing is shuffling nodes around: splitting up text nodes
and wrapping bits of them in new elements that you just inserted
before them, moving all the contents of an element next to it before
you remove it, etc.  Editors of various types seem like they're one of
the big use-cases for a mutation events replacement anyway, so my
guess is it's important.  But nobody's even made a list of use-cases
for mutation listeners, have they?

I don't think moving nodes is as common a use-case for typical sites.
But typical sites don't want mutation listeners either, so they aren't
what we should be concerned about here.

[Bug 13321] This is amazing! Awesome for multiplayer games!

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13321

Tab Atkins Jr.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jackalm...@gmail.com
 Resolution||INVALID

-- 
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: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

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

[Bug 13322] New: Add UDP! Quake uses UDP, I can't continue development of WebQuake because it uses UDP.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13322

   Summary: Add UDP! Quake uses UDP, I can't continue development
of WebQuake because it uses UDP.
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Add UDP! Quake uses UDP, I can't continue development of WebQuake because it
uses UDP.

Posted from: 91.201.230.187
User agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
WebMoney Advisor MRA 5.6 (build 03399);

-- 
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: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Ian Hickson]

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.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Bug 13321] New: This is amazing! Awesome for multiplayer games!

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13321

   Summary: This is amazing! Awesome for multiplayer games!
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
This is amazing! Awesome for multiplayer games!

Posted from: 91.201.230.187
User agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
WebMoney Advisor MRA 5.6 (build 03399);

-- 
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: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Anne van Kesteren]

On Thu, 21 Jul 2011 19:02:31 +0200, 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.


Actually it has. You are pretty required to support it these days and you  
better be sure you Accept-Encoding header is formatted consistently.



--
Anne van Kesteren
http://annevankesteren.nl/

RE: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[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 
> 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)

[Ian Hickson]

On Thu, 21 Jul 2011, Arthur Barstow wrote:
> 
> Given the Protocol is now in LC review, it seems relatively important to 
> align the API and Protocol.

The API and the protocal _are_ aligned. The protocol asks for the consumer 
to provide a list of extensions. Nothing in the protocol requires that 
this list of extensions be configurable by the consumer's user.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Anne van Kesteren]

On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow   
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.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Arthur Barstow]

Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail 
including this thread started by Adrian (Hixie's follow-up is [2]) and 
Adrian's general Web Sockets LC thread [3].


This bug is currently resolved as WontFix and this resolution is 
supported by at least Hixie and Jonas. Adrian, Takeshi and Greg have 
argued against this resolution (i.e. they do not support deflate-stream 
being a mandatory extension in the API).


What do others (Anne?, Maciej?, ...) think about this issue?

Given the Protocol is now in LC review, it seems relatively important to 
align the API and Protocol.


-Art Barstow

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0242.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0193.html

On 7/8/11 5:44 PM, ext Adrian Bateman wrote:

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: Mutation events replacement

[Olli Pettay]

On 07/21/2011 06:01 PM, Boris Zbarsky wrote:

On 7/21/11 5:08 AM, Dave Raggett wrote:

Thanks for the explanation. Apps would need a way to disable
notifications during such animation sequences, and would be able to find
another means to serialize the animation (at a higher level).


I'm not sure I trust apps to do that, which is why I think the default
behavior should be that they just don't get the information.


This raises the question is unregistering and re-regtistering a mutation
notification handler cheap or do we need an alternative mechanism for
temporarily suspending notifications?


Olli is better able than I to answer this for Gecko.


In the current WIP patch for mutation event replacement registering and
unregistering listeners is cheap, and if there are no listeners,
performance isn't affected at all.
This is with the sync approach.

If async approach is taken, listener handling becomes significantly
more complicated. What if the listener is added after the mutation has
happened, should it be called? If not, then we need to keep a list of
changes for all the listeners separately. If yes, then we need to
track all the changes all the time, even if there are no listeners.



-Olli

Re: Mutation events replacement

[Boris Zbarsky]

On 7/21/11 5:08 AM, Dave Raggett wrote:

Thanks for the explanation. Apps would need a way to disable
notifications during such animation sequences, and would be able to find
another means to serialize the animation (at a higher level).


I'm not sure I trust apps to do that, which is why I think the default 
behavior should be that they just don't get the information.



This raises the question is unregistering and re-regtistering a mutation
notification handler cheap or do we need an alternative mechanism for
temporarily suspending notifications?


Olli is better able than I to answer this for Gecko.

-Boris

Re: [websockets] Getting WebSockets API to Last Call

[Arthur Barstow]

Regarding the bugs Adrian identified in the e-mail below, here is my 
take on the status:


* Resolved: NeedsInfo: 9973, 12180, 13104; WontFix: 12816, 13178
* Moved to another component: 10213
* Open and considered Editorial (thus will not block LC): 12510, 13162, 
13180 and 13172 (not in Adrian's original list)


Since Adrian's email, Brian submitted two additional bugs that are Open:

13294 "The send() method should fail the WebSocket connection when data 
cannot be sent "

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13294

13295 "The "make disappear a WebSocket object" case should not fail the 
WebSocket connection"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295

Based on the various comments on 12917 (currently Resolved as WontFix), 
there is no consensus on this bug:


.

I will follow up separately on 12917 via the [1] thread.

Comments, corrections, etc. on the above status are welcome.

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0241.html

On 7/7/11 6:00 PM, ext Adrian Bateman wrote:

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" makeshttps: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: Mutation events replacement

[Dave Raggett]

On 20/07/11 21:34, David Flanagan wrote:

On 7/19/11 4:01 PM, Jonas Sicking wrote:

'listener' above would be a function which receives a single argument
when notifications fire. The value of this argument would be an Array
which could look something like this:

[ { target: node1, type: "childlist", added: [a, b, c, d], removed: 
[x, y] },
   { target: node1, type: "attributes", changed: ["class", "bgcolor", 
"href"] },

   { target: node2, type: "characterdata" },
   { target: node3, type: "childlist", added: [r, s, t, x], removed: 
[z] } ]



Given that childlist and attribute changes are merged together into 
arrays, there is, in general, no way to reconstruct the ordering of 
mutations.  In the example above, I'd assume that the first change to 
node1 occurred before the change to node 2.  But there are 8 other 
changes to node1 and we know nothing about their ordering relative to 
the others.


So, if mutation order is not preserved, is an array the right data 
structure for this unordered set of mutations?  There is a Map type 
proposed for ES.next that allows objects as keys: 
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets  
Would it be helpful to use that as the basis of this data structure?  
Or could DOMCore define a NodeMap type (to go along with NodeList?)


I don't have a specific use-case in mind, but I wanted to bring this 
up since I imagine it would be nice to be able to quickly find all 
mutations for a given target node without having to do a linear search 
with Array.filter() or similar.


David




For the distributed editing use case, preserving the order of mutations 
is critical as is being able to identity the nodes involved. In my 
editing application I serialize changes to the DOM as JSON as an array 
of changes where each change is an object with properties that name the 
node (via a tumbler notation), the operation (e.g. insert, remove, 
move), and additional operation specific properties. Each mutation event 
is added to a temporary queue of sets of reversible changes. The changes 
are periodically serialized and transmitted via websockets.  The queue 
of reversible changes includes the DOM nodes and this is exploited to 
permit undo/redo operations. The tumbler references are computed during 
the mutation event handler since they may well change before the 
mutation is serialized and transmitted to the server.


I listen to mutation events for a div element with the content editable 
flag. I don't use the execCommand API as it currently varies too much 
from one browser to the next. However, I do have to deal with how 
browsers change the DOM in response to keystrokes, especially, enter, 
backspace and delete. Inserting a node is expensive as I have to 
serialize all of its content nodes. This is why a move operation is 
valuable.


The local undo/redo queue of changes has to be updated to reflect 
changes by other editing clients, but that is another story!


--
 Dave Raggett  http://www.w3.org/People/Raggett

Re: Mutation events replacement

[Olli Pettay]

On 07/21/2011 01:56 AM, Jonas Sicking wrote:

On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay  wrote:

On 07/20/2011 06:46 PM, Jonas Sicking wrote:


Hence I'm leaning towards using the almost-asynchronous proposal for
now. If we end up getting the feedback from people that use mutation
events today that they won't be able to solve the same use cases, then
we can consider using the synchronous notifications. However I think
that it would be beneficial to try to go almost-async for now.


I disagree.


I had hoped for a bit more of an explanation than that ;-)

Such as why do you not think that synchronous events will be a problem
for web developers just like they have been for us?


In practice synchronous events have been a problem to us because we
are in C++, which is unsafe language. Web devs use JS.


The only C++ specific problem that we've had is dangling pointers.
However only a small set of our problems would have been solved by
making local points strong.


"only a small set of our problems" is a major understatement. Huge
number of problems have been fixed using either strong references or
things like nsWeakFrame (the original reason for nsWeakFrame was
to fix a class of bugs related to dangling pointers which were caused by
mutation event listeners doing something unexpected).



We'd still have problems with indexes changing under us, and nodes
that we removed from one location now being inserted elsewhere, etc.

Another way to look at it is that due to C++ specific problems, when
unexpected things happen during callbacks, we end up possibly
crashing. In Javascript, if unexpected things happen during callbacks,
you'll get buggy behavior. That's better, but still not good.


Web devs usually want something synchronous, like sync XHR
(sync XHR has other problems not related to mutation handling).
Synchronous is easier to understand.


That is a wholly different type of sync API. Those are APIs where the
return value is delivered through a callback rather than as a return
value, forcing you to create awkward code like:

doSomething(function(res1) {
   res1.callFunc(function(res2) {
 doSomethingElse(res2);
   }
}

There's a very good problem description here: http://tamejs.org/
(ignore the proposed solution, it's the problem description that's
interesting for this discussion).

Reading... will comment later.




Those problems aren't happening here as far as I can tell. There are
no return values delivered asynchronously, nor any of the problems
described in the tamejs page.

/ Jonas

Re: Mutation events replacement

[Dave Raggett]

On 20/07/11 18:23, Boris Zbarsky wrote:
It's pretty common to have situations where lots (10-20) of properties 
are set in inline style, especially in cases where the inline style is 
being changed via CSS2Properties from script (think animations and the 
like, where the objects being animated tend to have width, height, 
various margin/border/padding/background properties, top, left, etc 
all set).  Those are precisely the cases that are most 
performance-sensitive and where the overhead of serializing the style 
attribute on every mutation is highest due to the large number of 
properties set.


Thanks for the explanation. Apps would need a way to disable 
notifications during such animation sequences, and would be able to find 
another means to serialize the animation (at a higher level). This 
raises the question is unregistering and re-regtistering a mutation 
notification handler cheap or do we need an alternative mechanism for 
temporarily suspending notifications?


--
 Dave Raggett  http://www.w3.org/People/Raggett