Re: Push API draft update

[Chaals McCathieNevile]

On Tue, 28 Aug 2012 02:00:11 +0300, SULLIVAN, BRYAN L 
wrote:


Hi Art,

Can you update the Webapps Publication Status page to add Eduardo as  
co-editor of the Push API draft?


Done - you should be able to do it yourselves actually, using your normal  
W3C login credentials.


We are looking forward to feedback on this update, with the goal of  
getting to FPWD by TPAC if possible.


OK, noted.

cheers

Chaals


Thanks,
Bryan Sullivan
+

From: EDUARDO FULLEA CARRERA 
Date: Wed, 22 Aug 2012 07:48:49 +0200
To: "public-webapps (public-webapps@w3.org)" 
Cc: "bs3...@att.com" 
Message-id: <492d97b30609c54fa9ff98b847ea5682b975989...@exclu2k7.hi.inet>
Hi all,

Bryan Sullivan and myself have been working together on updating the  
Push API draft based upon feedback received and the work being driven by  
Mozilla and Telefonica to build a Push solution for Firefox OS (B2G).


You can find it at:  
http://dvcs.w3.org/hg/push/raw-file/default/index.html



This update does not intend to address yet each and every comment  
received, as some may deserve further discussions, but we think is a  
good step forward. We are looking forward to receiving your feedback.


Thanks and regards,
Eduardo Fullea
Telefonica Digital


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar  
nuestra política de envío y recepción de correo electrónico en el enlace  
situado más abajo.
This message is intended exclusively for its addressee. We only send and  
receive email on the basis of the terms set out at:

http://www.tid.es/ES/PAGINAS/disclaimer.aspx




--
Chaals - standards declaimer

Re: Acceptable for CSS to add a "window.CSS" global?

[Chaals McCathieNevile]

TL;DR: I disagree with the reasoning but I reach the same conclusion:
 window.CSS is worth trying.

On Sun, 19 Aug 2012 17:57:01 +0200, Tab Atkins Jr. 
wrote:


On Sun, Aug 19, 2012 at 3:59 AM, Chaals McCathieNevile 

On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack 



Chaals McCathieNevile:

Frankly, I am deeply sceptical that the CSS group has managed to solve
the social problem sufficiently well to make the technical solution
noticeably different from hasFeature.


I think the biggest difference between hasFeature and supportsCSS is  
that the implementation of the former, for a given feature string,

would be completely independent of the feature it is testing for.

...

Until some important site starts to use this to differentiate between
browsers. Since the primary job of a browser maker is to render the web  
for users, when a site blocks them for no real technical reason


I honestly hope supports works out - and believe it can. But that  
belief is not based on the idea that it is somehow fundamentally

different technically, but that it can combine something of a clean
slate, a slightly different implementation, and happening today and not
five years ago. So despite my concerns about how it works out with e.g.
"-webkit-*" I think it's worth trying.

But then, I am an eternal optimist.


While Opera has a history of lying to sites for compatibility reasons,
most other browsers do not.


Hmm. Modulo user agent strings that are all historic lies, and "most"
being the most popular rather than necessarily the greater proportion of
browsers, fair enough.


Even within practices such as Opera's, it's always limited to
particular sites which are problematic, rather than being a generic
lie to the web as a whole


No, that is not necessarily the case.


(which, in @supports's case, would almost certainly *break* plenty
of sites who *are* depending on that property being supported
properly).


Right. This is the potential concern that we all want to kep as a
potential rather than a real problem.

My rationale is that it is still easy to implement partial support (e.g.
get the CSS parser right, without getting everything else right). And real
motivations to do this exist, in the form of popular content that doesn't
work across browsers well because of coding issues rather than any real
technical difference.

There are plenty of examples of high-profile sites arbitrarily blocking
browsers, and of browsers providing workarounds. But there are also
examples of browsers simply hacking support for benchmarks (for the
logical reason that people read the top line but not the analysis).

The practice of serving "you should be using Netscape 3" (or the modern
equivalent) is still "widespread" - although I haven't done research to
get serious numbers, it is something that people seem happy to paste into
their code from some half-baked example.


Finally, the CSSWG's own practices of mandating prefixes before
compatibility is established means that it's unlikely that someone
will claim to support an unprefixed property before it's actually
ready.


I'm less convinced that the prefixing system is a success - and despite
thinking that it isn't stupid for DOM attributes as well, I think its
lifespan there is limited and the day will come when people start lying on
a fairly general basis about some properties because some popular site
didn't match their expectations to reality.

Hopefully, we can minimise this effect by maintaining social pressure on
developers to use such tools as these for "good" (enhancing users'
experience) rather than to "do evil" (discriminating by the colour of your
browser logo).


This sort of thing can still fail, of course. But it fixes several of
the problems that dragged hasFeature() down.


I'm unconvinced. I think that it tilts the cost/benefit ratio slightly in
favour of doing The Right Thing™ compared to hasFeature() and I think
people


In any case, it sounds like no one knows of any problems off the top
of their head with adding a new "window.CSS" object.


There is no concrete problem I can point to. I am nervous about the CSS
community slowly building an entire parallel universe that starts to
introduce real forks in the way things have to work, and ends up causing
some long-term major headache. That is just a worst-case scenario, but if
we get there we'll make a whole world of pain for a few years while we
figure out how to fix it.


Pending any compatibility studies showing problems,


We're flying by the seat of our pants here. If we discover compatibility
problems, it is reasonably likely that we lost the opportunity to fix them
without more pain than the industry will bear.


we'll go ahead and move forward with it.


'I'd like to say "Damn the torpedoes"' (The hunters and collectors already  
sang that line).


Yeah, despite the minor reservations, I think it is worth going ahead.

cheers

--
Chaals - standards declaimer

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 28

[Chaals McCathieNevile]

On Tue, 21 Aug 2012 14:20:34 +0200, Arthur Barstow   
wrote:


Marcos would like to publish a "Proposed Edited Recommendation" [PER] of  
the Widget Packaging and XML Configuration spec [REC] to incorporate the  
spec's errata and this is a Call for Consensus to do so.


I support (as an individual).

cheers

Chaals

--
Chaals - standards declaimer

Re: [widgets] P&C ready for pub - Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Chaals McCathieNevile]

On Mon, 20 Aug 2012 17:46:00 +0200, Marcos Caceres  wrote:

On Thursday, 9 August 2012 at 13:36, Marcos Caceres wrote:
On 9 Aug 2012, at 13:10, "Chaals McCathieNevile"  On  
Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow (mailto:art.bars...@nokia.com)> wrote:
> > Based on this discussion, I concluded this CfC has failed to show  
we have consensus. As such, after you two have agreed on a version of  
the spec that satisfies all of Chaals' concerns, my recommendation is  
we start a new CfC.

>
> Works for me. Marcos, should I just send you a snippet for references?

Yep. Would appreciate that.
To move this forward more quickly, I ended up adding them myself. Please  
check the doc over and let me know if it's all good to go. I think I've  
addressed everything.


Looks good to me.

cheers

Chaals

--
Chaals - standards declaimer

Re: Acceptable for CSS to add a "window.CSS" global?

[Chaals McCathieNevile]

On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack   
wrote:



Chaals McCathieNevile:

Frankly, I am deeply sceptical that the CSS group has managed to solve
the social problem sufficiently well to make the technical solution
noticeably different from hasFeature.


I think the biggest difference between hasFeature and supportsCSS is  
that the implementation of the former, for a given feature string, would  
be completely independent of the feature it is testing for.  So someone  
must make a judgement at some point about whether to return true for a  
given feature string.  With supportsCSS, I would imagine that it would  
return true or false by passing the string along to the CSS parser, so  
you would be much more likely to get an accurate answer out of it and  
there'd be no need for someone to make the judgement call.


Until some important site starts to use this to differentiate between  
browsers. Since the primary job of a browser maker is to render the web  
for users, when a site blocks them for no real technical reason the  
browser is likely to (and should) implement a work-around to make the site  
work. This is one area where hasFeature() failed. Another, and one which I  
suspect requires less social engineering to resolve, is the "look, we  
score XYZ on ShinyNewBenchmark.com" - by implementing just enough of  
something to pass the test without making it usable in practice.


I honestly hope supports works out - and believe it can. But that belief  
is not based on the idea that it is somehow fundamentally different  
technically, but that it can combine something of a clean slate, a  
slightly different implementation, and happening today and not five years  
ago. So despite my concerns about how it works out with e.g. "-webkit-*" I  
think it's worth trying.


But then, I am an eternal optimist.

cheers

Chaals

--
Chaals - standards declaimer

Re: [webcomponents]-ish: Visibility of work in Bugzilla

[Chaals McCathieNevile]

On Thu, 16 Aug 2012 19:29:06 +0200, Dimitri Glazkov   
wrote:



That's a great point. It's already tracking all of the Web Components
work (it looks like I am by far the spammiest -- not the best of
honors, but I'll take it). Perhaps we could just encourage people to
listen to that?


I suspect that is about the best approach...

cheers

Chaals


:DG<

On Thu, Aug 16, 2012 at 10:00 AM, Kang-Hao (Kenny) Lu
 wrote:

(12/08/17 0:36), Dimitri Glazkov wrote:

Another idea is to have a separate mailing list for this. At least,
there will be some opt-in step that will give other
public-webapps-nauts at choice.


We have public-webapps-bugzilla[1] already, but I have no idea why we
can't just turn on the component watching feature at the W3C Bugzilla
instance.

[1] http://lists.w3.org/Archives/Public/public-webapps-bugzilla/


Cheers,
Kenny
--
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/





--
Chaals - standards declaimer

Re: Acceptable for CSS to add a "window.CSS" global?

[Chaals McCathieNevile]

TL;DR: Conway's law is already validated in this instance, but maybe  
there's no real harm, and stuff to like about the proposal anyway. On  
balance I think it is a good idea. (Plus a lot of stuff about @supports  
...)


On Tue, 14 Aug 2012 01:59:28 +0200, Tab Atkins Jr.   
wrote:

On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson  wrote:

On Mon, 13 Aug 2012, Tab Atkins Jr. wrote:

The CSSWG would like to add a new top-level object called "CSS" that we
can hang several functions and constructors off of, so that we can  
avoid the excessive verbosity that's probably required if we just put

everything on window. [...]

Does anyone see any problems with this?  Do we think there's a
significant compat risk to claiming an all-caps "CSS" variable?


Seems reasonable in principle, but there's a risk of running into  
Conway's law [...]


The Conway's Law concern is reasonable, though minor.  Noted.


Hmm. I am not sure if it is minor or not. Depends how important you think  
clean architecture is - personally I think it is lovely but not something  
the Web has or relies on so I can live with what I think is a high  
probability of an API that reflects the CSS group more than anything  
else...



(Right now, the only thing we want to add is a "supports()" function,
which is the API version of the upcoming @supports rule.  In the  
future, we'd like to add things like the CSSOM Value API constructors

to it [...])


As a general rule, @supports and supports() sound like they're run into
the antipattern [of hasFeature() returning useless information]


@supports was designed very specifically to make this as small of a
problem as possible.

If a browser supports "foo: bar;" well enough to actually parse it and
keep it around, it's - by definition - good enough for authors to use
it.


Maybe (but I am unconvinced). But when a browser just *says* it can handle  
it, that is not good enough on its own.



While it's theoretically possible that a particular browser's
implementation is really shitty so that you don't want to use it, in
practice I don't think that's ever been a problem (or if it has, it's
been rare enough that I don't remember it).


Too make the thing useless for authors there doesn't have to be a terrible  
implementation, just different ones in different browsers. And browsers  
have differently implemented pretty basic parts of CSS before, unless my  
memory is playing tricks.



There's also a granularity issue. [...]


Valid in principle, but I don't think it's a big deal.  There are some
issues like that, but authors can know about them and work around
them.


Actually, this is the crux of the issue. Anything that relies on authors  
knowing the issues is something that makes the proposed use case for  
supports less interesting.


On the other hand, it doesn't have to work perfectly to be useful, it just  
has to work well enough often enough to make using it worthwhile.


[...]

The failure of hasFeature() greatly informed the design of this feature.


And yet the technical design boils down to the same thing - asking the  
browser a question about whether it can do something, where there is a  
penalty for answering "I can't".


The penalty, quite often, is being told to advertise a rival product to  
the user. Without wanting to anthopomorphise companies, and still less  
software, this is something that hurts both the dignity and actual  
well-being of the browser, so the motivation to stretch the truth (an in  
equal measure distort what this feature tries to do) is pretty strong.


The issue is social - if it were worse to lie in hasFeature than not  
having the feature requested, there would be no need for supports() since  
we could just add the CSS tests to hasFeature.


Frankly, I am deeply sceptical that the CSS group has managed to solve the  
social problem sufficiently well to make the technical solution noticeably  
different from hasFeature.


Which leads me to the conclusion that "Conway's Law" has already been  
borne out here.


However...


If you'd like to discuss the supports() function further, could you do
it on www-style?  I'd prefer this thread to stay on the original
subject.


Right.

As Odin said, window.* is a pretty big collection, and being able to  
simplify CSS-specific stuff is probably going to bring more value than  
problems. Overall, I think the idea is reasonable.


cheers

Chaals

--
Chaals - standards declaimer

Re: Web Components Suggestion

[Chaals McCathieNevile]

On Mon, 13 Aug 2012 10:47:22 +0200, Florian Bösch  wrote:


On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith  wrote:

There is no conceivable conformance checker that's going to allow the  
use of completely arbitrary tag names. It doesn't matter what formalism

it uses.
To allow custom tag names and still be able to check the conformance of
normal tag names, the only possibility is to limit the custom tag names  
to some recognized prefix -- e.g., x-fancyButton or whatever.





Yes, XML has a way to make this work. But the people who don't get
namespaces (a huge proportion of those publishing content or build the
content content generation tools that were used in the last decade *on the
public web*) have convinced us* that this is not an option for HTML.

On the other hand, a log of programming languages manage to run a compiler  
that recognises arbitrary elements based on a grammar and an "import"  
declaration of some kind.


In other words, they use a simplistic namespace mechanism (without the  
collision-control).


*For some definition of us. For those who have worked happily with  
namespaces over the last decade, writing HTML5 as XHTML is a reasonable  
option, if the browsers don't scrap their XML capability.


cheers

Chaals

--
Chaals - standards declaimer

Re: [IndexedDB] Problems unprefixing IndexedDB

[Chaals McCathieNevile]

On Thu, 09 Aug 2012 14:53:06 +0200, Robin Berjon  wrote:


On Aug 9, 2012, at 02:28 , Boris Zbarsky wrote:

On 8/8/12 8:23 PM, Adam Barth wrote:

If we're telling people to use that pattern, we might as well just not
prefix the API in the first place because that pattern just tells the
web developers to unilaterally unprefix the API themselves.


Yep.  The only benefit of the prefixing at that point is to maybe mark  
the API as experimental, if any web developers pay attention.  Which I  
doubt.


Trying to evangelise that something is experimental is unlikely to  
succeed. But when trying out a new API people do look at the console a  
lot (you tend to have to :). It might be useful to emit a warning upon  
the first usage of an experimental interface, of the kind "You are using  
WormholeTeleportation which is an experimental API and may change  
radically at any time. You have been warned."


Actually, you should say "*will* change, and *will*stop*working* after  
some time. If you don't update your code, we will break it".


cheers

--
Chaals - standards declaimer

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Chaals McCathieNevile]

On Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow   
wrote:



Chaals, Marcos,

Based on this discussion, I concluded this CfC has failed to show we  
have consensus. As such, after you two have agreed on a version of the  
spec that satisfies all of Chaals' concerns, my recommendation is we  
start a new CfC.


Works for me. Marcos, should I just send you a snippet for references?

cheers


-Thanks, AB

On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote:
On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres   
wrote:



On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote:

On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow  
mailto:art.bars...@nokia.com)>

wrote:

> Marcos would like to publish a "Proposed Edited Recommendation"  
[PER] > of the Widget Packaging and XML Configuration spec [REC] to

> incorporate the spec's errata and this is a Call for Consensus to do
> so.

Currently I object. I would support the publication if:

1. It restored the pointer to an external errata document (Marcos is
clever, but there may still be errata) and


Not sure what you mean here (and not just about being clever!:) )?  
There is a pointer to errata…

http://dev.w3.org/2006/waf/widgets/errata.html
It's right at the top of the document? What am I missing?


The new version says that it incorporates the errata there, but removes  
the statement that any further errata might be found at the same place.  
I suggest reinstating the text that was taken out, since there may be a  
need for errata on this document (personally I would prefer to see a  
new version, allowing for example internationalisation of more elements)


2. It restored the status of the document to cover patent policy and  
where to send feedback and


Ah, sorry… SoTD was from the editor's draft. I need to find a  
boilerplate for a PER. I'm going to copy the one from XML 5th Ed., but  
it's a bit of work so I'll do it RSN.


OK, please do.


3. It fixes the normative references to include authors and point to
stable versions.


I will only link to "stable" versions for normative references -  
informative references don't matter.


I can live with that. However I note that it is useful to know what  
version of something that you used as an informative reference was the  
one you actually read. HTML5 is different from what it was when P&C was  
published. For most cases it doesn't matter (it is useful to have a  
link to the latest and greatest version with all the brilliant ideas  
the editor had after a saturday-night binge included), but for careful  
use of the documents it can actually make a material difference.


Re editors: can't find anything in the process document that requires  
them to be added.


1. It is a generally accepted convention that assists in recognising a  
reference, particularly from a printed version (yes, people still print  
specifications, often. There are sound reasons why this is likely to  
continue for some years).
2. Many of these publications are essentially volunteer work. The  
efforts of the editors (or the money of their employers that supports  
them taking on the work) are often motivated in part by the fact that  
their name is cited by convention. I don't see the use case for  
breaking this convention, and the small benefit that it provides to  
those who edit specifications.



Of course, you are more than invited to add them yourself to the
spec if you really want.


Sure, I can do that.

They were in the REC, so you can copy/paste them from there (or email  
me the markup and I'll paste them in for you). However, I see no use  
case for including them given that there is a hyperlink to their spec  
(which already lists them).


Cheers

Chaals







--
Chaals - standards declaimer

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Chaals McCathieNevile]

On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres  wrote:


On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote:

On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow  
mailto:art.bars...@nokia.com)>

wrote:

> Marcos would like to publish a "Proposed Edited Recommendation" [PER]  
> of the Widget Packaging and XML Configuration spec [REC] to

> incorporate the spec's errata and this is a Call for Consensus to do
> so.

Currently I object. I would support the publication if:

1. It restored the pointer to an external errata document (Marcos is
clever, but there may still be errata) and


Not sure what you mean here (and not just about being clever!:) )? There  
is a pointer to errata…

http://dev.w3.org/2006/waf/widgets/errata.html
It's right at the top of the document? What am I missing?


The new version says that it incorporates the errata there, but removes  
the statement that any further errata might be found at the same place. I  
suggest reinstating the text that was taken out, since there may be a need  
for errata on this document (personally I would prefer to see a new  
version, allowing for example internationalisation of more elements)


2. It restored the status of the document to cover patent policy and  
where to send feedback and


Ah, sorry… SoTD was from the editor's draft. I need to find a  
boilerplate for a PER. I'm going to copy the one from XML 5th Ed., but  
it's a bit of work so I'll do it RSN.


OK, please do.


3. It fixes the normative references to include authors and point to
stable versions.


I will only link to "stable" versions for normative references -  
informative references don't matter.


I can live with that. However I note that it is useful to know what  
version of something that you used as an informative reference was the one  
you actually read. HTML5 is different from what it was when P&C was  
published. For most cases it doesn't matter (it is useful to have a link  
to the latest and greatest version with all the brilliant ideas the editor  
had after a saturday-night binge included), but for careful use of the  
documents it can actually make a material difference.


Re editors: can't find anything in the process document that requires  
them to be added.


1. It is a generally accepted convention that assists in recognising a  
reference, particularly from a printed version (yes, people still print  
specifications, often. There are sound reasons why this is likely to  
continue for some years).
2. Many of these publications are essentially volunteer work. The efforts  
of the editors (or the money of their employers that supports them taking  
on the work) are often motivated in part by the fact that their name is  
cited by convention. I don't see the use case for breaking this  
convention, and the small benefit that it provides to those who edit  
specifications.



Of course, you are more than invited to add them  yourself to the
spec if you really want.


Sure, I can do that.

They were in the REC, so you can copy/paste them from there (or email me  
the markup and I'll paste them in for you). However, I see no use case  
for including them given that there is a hyperlink to their spec (which  
already lists them).


Cheers

Chaals

--
Chaals - standards declaimer

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8

[Chaals McCathieNevile]

On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow   
wrote:


Marcos would like to publish a "Proposed Edited Recommendation" [PER] of  
the Widget Packaging and XML Configuration spec [REC] to incorporate the  
spec's errata and this is a Call for Consensus to do so.


Currently I object. I would support the publication if:

1. It restored the pointer to an external errata document (Marcos is  
clever, but there may still be errata) and
2. It restored the status of the document to cover patent policy and where  
to send feedback and
3. It fixes the normative references to include authors and point to  
stable versions.


The [Errata] has already been reflected in the [Proposed-PER] (see  
[Diff]) and it includes a new title of "Packaged Web Apps (Widgets) -  
Packaging and XML Configuration".


I agree with that colour for the shed...

cheers

Chaals

Please send all comments regarding this CfC to the public-webapps@w3.org  
mail list by August 8 and note silence will be considered as agreement  
with the proposal. If you support this CfC, a positive response is  
preferred and encouraged.


-Thanks, AB

[PER] 
[REC] 
[Errata] 
[Proposed-PER] 
[Diff]  



 Original Message 
Subject: 	Re: [widgets] Request to publish is P&C as Proposed Edited  
Recommendation

Date:   Tue, 24 Jul 2012 12:49:34 +0100
From:   ext Marcos Caceres 
To: 
CC: Barstow Arthur 



On Tuesday, 24 July 2012 at 12:27, Marcos Caceres wrote:

Earlier this year I corrected a bunch of things in P&C (see [errata]),  
so I think it would be good to republish the spec. Also, with the name  
of the spec still being cited as an "issue", I've changed the name of  
the specification to "Packaged Web Apps (Widgets) - Packaging and XML  
Configuration". Hopefully that new coat of paint will stick to the  
bikeshed. I would kindly request a CFC to republish.


Kind regards,
Marcos



[errata] http://dev.w3.org/2006/waf/widgets/errata.html










--
Chaals - standards declaimer

Re: [Server-Sent Events] Network connection clarification

[Chaals McCathieNevile]

On Wed, 11 Jul 2012 00:52:06 +0200, Ian Hickson  wrote:


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.


It would seem below that you are providing reasons why UAs can do better  
than that, and better than individual authors (apart from the question of  
whether it is better to have a couple of dozen UAs write the code, or  
every app developer do so)...



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.


I think it is something to consider as a bug in v1 - UAs can decide to  
fail eventually, but a single dropped connection seems like a poor reason  
to do so given the still somewhat flaky network we have around the world  
today. Living in Western European capitals with relatively good  
infrastructure, I find simple network dropout on fixed "broadband"  
networks far more common that something like entering a tunnel.


cheers

Chaals

--
Chaals - standards declaimer

change of affiliation

[Chaals McCathieNevile]

Hi all,

after today I will no longer be working for Opera. I will remain chair of  
web-apps as an invited expert.


After a break I will be working for Yandex, the Russian search and  
services company...


cheers

Chaals

--
Chaals - standards declaimer