Re: [Server-Sent Events] Network connection clarification

2012-07-10 Thread Glenn Maynard 
On Tue, Jul 10, 2012 at 4:44 PM, Tab Atkins Jr. wrote:

> This can be handled easily and competently by browsers.


Also, browsers can do this much better than scripts.  The browser can tell
immediately when a network connection, shared proxy connection, etc. become
available, avoiding unnecessary delays.  For example, when a bus exits a
tunnel and the connection is restored, or a mobile device switching from 3G
to wifi, or a desktop system being assigned a new IP by a DHCP server; in
all of these cases, the browser should reestablish the connection
immediately, as soon as the connection becomes available again.

Users can't do this in scripts, and these are system and platform-specific
details that users shouldn't have to care about.

-- 
Glenn Maynard

Re: [Server-Sent Events] Network connection clarification

2012-07-10 Thread Ian Hickson 
On Tue, 10 Jul 2012, Kornel Lesi�~Dski wrote:
> 
> However, I'm afraid that the most common implementation (aside from 
> complete lack of error recovery) will be a simple as 30-second retry 
> interval and that won't be very DoS-safe. UAs can do better than that.

That's not entirely clear.


> For example the spec could require UAs to have randomized retry interval 
> and exponential backoff on failure. Is there anything more that authors 
> could do client-side to avoid DoSing?

Exponential back-off isn't at all necessarily the right solution. In 
particular, consider mobile devices, where network connectivity goes in 
and out as the user moves. Most of the time, you want to be trying to 
connect as soon as you have connectivity. Similarly with laptops on wifi 
where the connection is only briefly hurt by an obstacle -- you want to 
keep trying every few seconds until the obstacle is gone. Exponential 
backoff if a terrible thing in those kinds of situations.

You can distinguish local network difficulties from server load 
difficulties in a variety of ways, e.g. having a dedicated ping server on 
the same network as the "real" server, which doesn't suffer from the same 
load concerns, and which you try to contact and only switch to exponential 
backoff if it responds but the main server isn't. And so on. UAs can do 
that kind of thing.


> SSE is mostly a convenience API (advanced authors can use streaming XHR 
> or WebSockets to achieve the same result the hard way), so lack of 
> convenience in error recovery feels like an omission in this API.

If it's something we do want to eventually support, I think it's be 
something to consider for v2.

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

Re: [Server-Sent Events] Network connection clarification

2012-07-10 Thread Tab Atkins Jr. 
On Tue, Jul 10, 2012 at 2:27 PM, Kornel Lesiński  wrote:
> On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson  wrote:
>> The idea is to let the script handle network troubles, so that authors are
>> in full control of how much load their servers get when they are having
>> trouble. The alternative is that UAs will DOS networks without the
>> networks having a way to gracefully reduce it.
>
> I share the concern about DoSing.
>
> However, I'm afraid that the most common implementation (aside from complete
> lack of error recovery) will be a simple as 30-second retry interval and
> that won't be very DoS-safe. UAs can do better than that.
>
> For example the spec could require UAs to have randomized retry interval and
> exponential backoff on failure. Is there anything more that authors could do
> client-side to avoid DoSing?
>
> It'll be easier to get handful of UAs to implement robust recovery by
> default than to expect each and every author to do that.

Yes, this has been said before.  It's unlikely that most authors will
even realize they need to handle reconnects - EventSource is just so
simple and easy to use, it seems crazy that we'd have to hold its hand
through that.  A lot of apps will break for no reason, just because
someone's network hiccuped for 30 seconds or so.

For those that do put in reconnects, doing it right isn't hard, but is
definitely non-trivial.  You want, as Kornel says, to do exponential
backoff with some random wiggle in intervals.  A naive 30s retry
interval, as you suggest, is actually *very likely* to accidentally
DoS the servers if the hiccup was somewhere on the server's side.  If
it's on the user's side, and they have multiple apps using EventSource
which are all set up on 30s reconnects, having all of them pound the
user's connection every 30s isn't great either.

This can be handled easily and competently by browsers.  There is no
strong reason for authors to want to customize their reconnection
behavior.  The only possibility I can see with a possibly use-case is
to deny reconnections entirely, but I can't come up with one off the
top of my head, and this should be the non-default behavior if we do
offer it.

In short, the current EventSource behavior is very likely to produce
wrong defaults in most cases, breaking apps for no good reason.
Correct reconnection behavior is easy but non-trivial.  Browsers can
very simply do it all themselves, and take into account multiple
EventSources spread across multiple apps with smart behavior.

~TJ

[Bug 17263] Keep on having send(ArrayBuffer data) interface in addition to send(ArrayBufferView data)

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #8 from Ian 'Hixie' Hickson  2012-07-10 21:39:48 UTC 
---
It's harmful just because it's extra API surface area.

-- 
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 16927] HTML reference was changed from W3C version to WHATWG version

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16927

Julian Reschke  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #2 from Julian Reschke  2012-07-10 21:38:01 
UTC ---
How can you see it did not, when it did?

, retrieved right now, says:

"[HTML]
HTML, I. Hickson. WHATWG."

Do I need to attach a snapshot to the bug?

-- 
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 17224] Possible typo in section 6: Ping and Pong Frames

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

--- Comment #2 from Ian 'Hixie' Hickson  2012-07-10 21:37:20 UTC 
---
The word "send" was extraneous.

-- 
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 17262] send function should have async interface

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||i...@hixie.ch
 Resolution||WORKSFORME

--- Comment #22 from Ian 'Hixie' Hickson  2012-07-10 21:35:40 
UTC ---
I don't understand what this bug has to do with the WebSockets API. The send()
method in WebSockets is already implementable in a completely async manner.
It's up to the browser to get a copy-on-write reference to the underlying data,
but that's an implementation detail.

-- 
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: [Server-Sent Events] Network connection clarification

2012-07-10 Thread Kornel Lesiński 

On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson  wrote:

The idea is to let the script handle network troubles, so that authors  
are in full control of how much load their servers get when they are  
having

trouble. The alternative is that UAs will DOS networks without the
networks having a way to gracefully reduce it.


I share the concern about DoSing.

However, I'm afraid that the most common implementation (aside from  
complete lack of error recovery) will be a simple as 30-second retry  
interval and that won't be very DoS-safe. UAs can do better than that.


For example the spec could require UAs to have randomized retry interval  
and exponential backoff on failure. Is there anything more that authors  
could do client-side to avoid DoSing?


It'll be easier to get handful of UAs to implement robust recovery by  
default than to expect each and every author to do that.


I'm not sure whether online/offline events are quick and reliable enough  
to speed up reconnection after network failure on client side, but most  
UAs could observe network on system level and avoid waiting too long time  
after temporary network signal loss. I doubt many authors will implement  
recovery as sophisticated as that.


There's "retry" directive in the SSE protocol, so authors have some  
control already (server under load can send retry: 9 or site-specific  
control message and close the connection). If that's not enough, then I  
think it'd be better to give authors more control of UAs auto-reconnect  
features, rather than expect all authors to better than UAs with their  
implementation from scratch.


SSE is mostly a convenience API (advanced authors can use streaming XHR or  
WebSockets to achieve the same result the hard way), so lack of  
convenience in error recovery feels like an omission in this API.


--
regards, Kornel Lesiński

[Bug 16927] HTML reference was changed from W3C version to WHATWG version

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16927

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||INVALID

--- Comment #1 from Ian 'Hixie' Hickson  2012-07-10 21:28:01 UTC 
---
It didn't, it changed _to_ the CR.

-- 
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 16730] Shared workers - use .source instead of .ports[0] ?

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16730

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WORKSFORME

--- Comment #1 from Ian 'Hixie' Hickson  2012-07-10 21:27:05 UTC 
---
this was resolved by e-mail, I believe

-- 
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 15719] Under section "Disk Space", there seems to be a word missing in the sentence (see part in parens): "User agents should guard against sites storing data (under the origins other affiliate

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15719

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
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 13686] Add example of calling start() on a port

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13686

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

-- 
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 16866] EOF is no longer valid as newline so "and the end of the file being the four ways in which a line can end" should be removed.

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16866

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

-- 
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: [Server-Sent Events] Network connection clarification

2012-07-10 Thread Ian Hickson 
On Sun, 29 Apr 2012, Neil Jenkins wrote:
>
> In response to the request for comments on server-sent events, I believe 
> the definition of when to fail a connection needs clarification and/or 
> adjustment.
> 
> Specifically, in Section 5 Processing Model, the line:
> 
> "Any other HTTP response code not listed here, and any network error 
> that prevents the HTTP connection from being established in the first 
> place (e.g. DNS errors), must cause the user agent to fail the 
> connection."
> 
> Combined with the definition of "fail the connection"...
> 
> "When a user agent is to fail the connection, the user agent must queue 
> a task which, if the readyState attribute is set to a value other than 
> CLOSED, sets the readyState attribute to CLOSED and fires a simple event 
> named error at the EventSource object. Once the user agent has failed 
> the connection, it does not attempt to reconnect!"
> 
> this seems to imply that if there is no internet connection 
> currently present, the EventSource connection will fail and not attempt 
> to reconnect.

Correct. EventSource is intended to not ever reconnect except in the case 
of the server being fine.


> This obviously reduces its usefulness. For example:
> 
> - A user is connected to the internet via 3G on a train and passes
>   through a tunnel. The connection is lost, so the EventSource
>   object tries to reconnect after x (say 30) seconds.

Right, though that's more of a side-effect of the design than intended. 
The reconnection logic is intended for the case of a server wanting the 
user agent to reconnect because it's shifting its load (e.g. when you have 
a cluster of machines behind a load balancer and one of the machines is 
being taken down so needs to offload its connections to others on the 
cluster) or because it knows no events will be coming any time soon. That 
it happens to also mean that a network break will result in a reconnection 
(once) is an unfortunate side-effect.


>   If, when this
>   first reconnection attempt happens, the user has still not
>   regained a network connection, it will fail permanently and never
>   reconnect again.

Right. The script is supposed to be the one doing the reconnecting.


> - When a computer wakes from sleep, there is often a delay before the
>   network connection is re-established; this creates a race condition -
>   if the EventSource attempts to reconnect before the network is
>   reestablished it again fails permanently.

Right. Again, it's only because it's hard to distinguish this case from 
the server closing the connection that there's any attempt to reconnect at 
all.


> In my opinion, the failure due to the absence of an internet connection 
> should be a temporary failure, and should ideally schedule a 
> reconnection attempt when the computer next finds a network. The current 
> spec seems to explicitly disallow this, although some browsers are 
> attempting to reconnect anyway.

The idea is to let the script handle network troubles, so that authors are 
in full control of how much load their servers get when they are having 
trouble. The alternative is that UAs will DOS networks without the 
networks having a way to gracefully reduce it.

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

[Bug 17736] New: Get "dereference" Blob URI terminology more in keeping with HTML5

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17736

   Summary: Get "dereference" Blob URI terminology more in keeping
with HTML5
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: a...@mozilla.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


Currently, the File API makes use of the terminology "dereference..." when
talking about the Blob URI.

HTML5 uses this to refer to javascript: URIs, but also "Fetch" to refer to
URLs.

We should make this consistent.

-- 
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 17675] Parameters to slice

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17675

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Arun  2012-07-10 16:42:59 UTC ---
Agreed; this change is long overdue, so thanks for catching it in a bug.

Done.

-- 
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: Firefox 16 will ship unprefixed IndexedDB

2012-07-10 Thread Joshua Bell 
On Mon, Jul 9, 2012 at 9:13 PM, Jonas Sicking  wrote:

> Hi All,
>
> Just wanted to give a status update regarding IndexedDB. Over the last
> few weeks we at Mozilla has combed through the spec and fixed any
> discrepancies that we found. The result is that we now think that we
> are up to par with the spec. Hence we are unprefixing our indexedDB
> implementation!
>
> We expect that there will be further changes to the spec, and that we
> will find more bugs, in which case we'll of course change our code to
> fix them. The unprefixing will in no way affect how willing we are to
> do so, so this will have no effect on the standardization process.
>
> However I thought it was a cool milestone that I thought was worth sharing!


Indeed it is - congratulations!

[Bug 17733] please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17733

Ms2ger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ms2...@gmail.com
 Resolution||DUPLICATE

--- Comment #1 from Ms2ger  2012-07-10 13:24:23 UTC ---


*** This bug has been marked as a duplicate of bug 17732 ***

-- 
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 17734] please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17734

Ms2ger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ms2...@gmail.com
 Resolution||DUPLICATE

--- Comment #1 from Ms2ger  2012-07-10 13:24:26 UTC ---


*** This bug has been marked as a duplicate of bug 17732 ***

-- 
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 17732] please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17732

Ms2ger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ms2...@gmail.com
 Resolution||NEEDSINFO

-- 
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 17734] New: please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17734

   Summary: please provide how to connect the url and how retrieve
the json web service  please prove one sample code ,my
mail id is   rajasek...@sipl.co.in
   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: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


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

Comment:
please provide how to connect the url and how retrieve the json web service 

please prove one sample code ,my mail id is   rajasek...@sipl.co.in   

Posted from: 122.166.104.98
User agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

-- 
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 17733] New: please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17733

   Summary: please provide how to connect the url and how retrieve
the json web service  please prove one sample code ,my
mail id is   rajasek...@sipl.co.in
   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: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


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

Comment:
please provide how to connect the url and how retrieve the json web service 

please prove one sample code ,my mail id is   rajasek...@sipl.co.in   

Posted from: 122.166.104.98
User agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

-- 
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 17732] New: please provide how to connect the url and how retrieve the json web service please prove one sample code ,my mail id is rajasek...@sipl.co.in

2012-07-10 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17732

   Summary: please provide how to connect the url and how retrieve
the json web service  please prove one sample code ,my
mail id is   rajasek...@sipl.co.in
   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: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


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

Comment:
please provide how to connect the url and how retrieve the json web service 

please prove one sample code ,my mail id is   rajasek...@sipl.co.in   

Posted from: 122.166.104.98
User agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

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