Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, 12 Jun 2012 02:56:00 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 17 Apr 2012, Odin Hørthe Omdal wrote: If I understand correcly, the spec expects the implementation to keep reconnecting indefinitely, when the network cable is yanked. No. The spec says 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. and Once the user agent has failed the connection, it does not attempt to reconnect. (In particular, note that reestablish the connection only ever occurs if the remote resource is actually obtained with the right MIME type.) We implemented it like that in Opera, except that we do in fact try reconnecting a bit before giving up and firing the error event. However, as I said, that's not what the others do, so we want to align somewhere - either us following the rest, or the rest following us. Not really important what way it goes. Looking into it, however, I do see some nice benefits when keeping the connection always reconnecting like that. If you're on a page on your phone, on a Wifi connection, you go away from your home and take the bus. After one hour you get to work, there you get a new Wifi connection and the web page on your phone starts doing what it was up to before - even though the web page author never really thought about that. On the other hand, for rockstar web page authors, it's nicer to control that yourself. However, doing that, the browser doesn't know what you're doing in your setInterval calls, and thus it's a bit harder to be smart about it. If it is doing the reconnections itself, it can have different heuristics and algorithms to control the behaviour. I tried yanking the network for 10+ minutes, and when I put the cable in again, both Firefox and Chromium used 25 seconds to reconnect. When only yanking it for one minute, the reconnection was much faster (2-5 seconds). This with *reconnection time* set to 500ms. As far as I can tell, none of that is conforming. If you yank the cable, they should retry once, then give up, per the spec. So... To be really spec-conforming, we'd have to be superduper-strict? I wouldn't mind, but I *do* mind when the other engines do something completely different :-) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
[Bug 17467] Established in 2003, http://www.fashionskateshoes.com, was born out of the streets desire for urban biased fashion. When SUPRA,NIKE NEW BALANCE,GUCCI were causing waves in the early 2000
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17467 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- 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.
[DOM4] Mutation algorithm imposed order on document children
Elliott, All - please use the www-...@w3.org list for DOM4 discussions http://lists.w3.org/Archives/Public/www-dom/. (Elliott, since that spec is still in the draft phase, you should probably use the latest Editor's Draft http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html instead of the version in w3.org/TR/) -Thanks, AB Original Message Subject:[DOM4] Mutation algorithm imposed order on document children Resent-Date:Tue, 12 Jun 2012 01:01:51 + Resent-From:public-webapps@w3.org Date: Mon, 11 Jun 2012 16:39:36 -0700 From: ext Elliott Sprehn espr...@gmail.com To: public-webapps@w3.org I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm and one of the bugs is not throwing an exception when a doctype node is inserted after an element in a document (or other permutations of the same situation). https://bugs.webkit.org/show_bug.cgi?id=88682 http://www.w3.org/TR/domcore/#mutation-algorithms After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Specifically since inserting a doctype node doesn't actually change the doctype so this situation is very unlikely (possibly never happens) in the wild. Not implementing this keeps the code simpler for a case that developers likely never see. Can we leave the behavior when your document is out of order unspecified? - Elliott
Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, Jun 12, 2012 at 3:48 AM, Odin Hørthe Omdal odi...@opera.com wrote: If you're on a page on your phone, on a Wifi connection, you go away from your home and take the bus. After one hour you get to work, there you get a new Wifi connection and the web page on your phone starts doing what it was up to before - even though the web page author never really thought about that. What's the rationale behind the spec saying not to reconnect at all? If the API makes each app individually handle reconnects, then not only does it push more work on web developers, it'll create two problems: apps that attempt reconnects too rapidly, and ones that--as Odin points out--don't reconnect at all because the developer didn't know he had to. Too rapid reconnects will probably be a common problem. A naive implementation will just retry on a period, eg. every 30 seconds, which will cause the usual problems: a server goes down, and every client begins its 30-second delay at the same time, causing the server to be hammered with requests every 30 seconds. The usual solution to this is using a random factor in the delay, plus an exponential (or at least increasing) delay time. It would also make sense for the web app to be able to tell that it's in a retrying state. That is, it's not connected and according to the current spec would have received an error, but it's not in an error state either (retries are still ongoing), so the app can display that it's offline. This also lets the app know that some messages may have been missed (though that can be done at the application level with a sequence number). On the other hand, for rockstar web page authors, it's nicer to control that yourself. However, doing that, the browser doesn't know what you're doing in your setInterval calls, and thus it's a bit harder to be smart about it. If it is doing the reconnections itself, it can have different heuristics and algorithms to control the behaviour. There are a lot of these. For example, the browser knows when a connection becomes available. If you're on mobile it'll know when a wifi or cell data connection becomes available, and can open a new connection right away instead of waiting unnecessarily. It knows if there's no connection at all, so it can go to sleep and not waste battery with retries. On desktop browsers, it knows when a network cable is plugged in, and if the machine's IP address changes. This is all information that can be used to adjust the reconnect timing. -- Glenn Maynard
Web Activities: counter-proposal to Web Intents
Hi, With some people at Mozilla, we've been working on an API similar to Web Intents in some points but distant enough to be a counter-proposal. We believe that the API is now in a good enough shape to be officially sent in those mailing lists and discussed. You can have an overview of the API here:https://wiki.mozilla.org/WebAPI/WebActivities Web Activities' intent is not to be a clone of Google's Web Intents with some naming and API details changed. Web Activities aim to be a simple API trying to solve a very clear set of use cases. It has been a bit hard to judge the desired scope of Web Intents. People have suggested that Intents should be able to solve everything from getting low-level Sensor information [1] to the ability to implement services like Push Notifications [2] to doing discovery and control of DVR hardware from the browser [3]. It is unclear if this is just a list of things people wish that Intents could help with, or if these are hard requirements that the spec authors are using to design the spec for. An API which allows building a wide range of applications is generally a good API, however it is also important to have a concrete set of use cases when designing an API to make sure that it solves those use cases well. Our concern is that Intents are designed to solve the ambigious use case of communicating with anything. As a reminder, the basic use cases of Web Intents seem to be: Users use many different services on the web to handle their day to day tasks, such as sharing images, editing documents and listening to music. They expect their applications to be connected and to work together seamlessly. [4] and the basic actions/intents/activities the API mentions are share, edit, view, pick [4]. The current shape of Web Intents seems to allow consumers of the API to use it for: 1. Delegating: an application delegates an activity to another application. 2. Discovery: some consumers seem to be inclined to use Web Intents to discover other services. This is what Bryan Sullivan suggested for the Push Notification API. When the Intent is invoked no action would actually be taken, instead a URL is returned and then it's up to the page to communicate with that URL with the Web Intent API no longer involved. 3. Communication: you can use Web Intents to simply create a channel of communication between APP A and APP B: you can easily specify which service should be used to handle the intent and then, you can communicate with it. We believe we should restrain the API to (1). (2) is something that is better done with a separate Discovery API since the model here is very different. It is no longer transparent to the two parties involved who they are communicating with, and the UA no longer has the ability to mediate the communication. (3) is something that can be solved with already existing parts of the platform, like MessageChannel or WebSockets. The main issue we see with trying to solve all those use cases in one API is regarding implementation and especially UI. The way we see it, when an application wants to start an activity/intent, a UI should show the list of applications able to handle it, and it should be clear to the user that this application will be used to complete the action he/she intended to do. For example, if the user clicks on the camera button, a UI will ask him/her which application should be used to pick/take a picture. If you try to mix (2) and (3) in here, you will have serious problems like an application initializing a communication channel with another application at startup: the user might see a UI asking him/her to chose an application in the list but will have no idea why and for what. This could apply for the Push Notification case: the UA cannot know that the intent/activity was sent to discover a push service instead of delegating an activity to it. Actually, for security purposes, we are even going to limit activities so they can be started only when generated from a user action. Basically, we think Web Activity should be a very simple API that allows an application to delegate an activity to another application with very clear rules regarding starting the activity, handling it and the UI in-between. Another simple API could be used to do (2) and (3). Basically, you can imagine an API that would allow you to discover a service doing foo and if the service agrees, both parts will get a MessageChannel port they can use to communicate with each other. This API is out of scope of Web Activites but might be helpful for applications that want to discover services and communicate with them in the background. So, we would like to suggest, if Google agrees, to work together on a common version of that API that would be restricted to the use cases we mentioned. It could be based on Web Activities (or Web Intents stripped from all unnecessary stuff). We are willing to discuss any detail of the API as long as we do not include any feature we believe are out of
Re: Web Activities: counter-proposal to Web Intents
On 12/6/12 16:08 , Mounir Lamouri wrote: 2. Discovery: some consumers seem to be inclined to use Web Intents to discover other services. This is what Bryan Sullivan suggested for the Push Notification API. When the Intent is invoked no action would actually be taken, instead a URL is returned and then it's up to the page to communicate with that URL with the Web Intent API no longer involved. JCD: Web intents does not provide discovery, but more like a directory service. Your proposal also provides registration and a sort of directory service, even if you do not provide a matching algorithm. So your proposal is more or less at the same level of functionality than web intents in this respect. 3. Communication: you can use Web Intents to simply create a channel of communication between APP A and APP B: you can easily specify which service should be used to handle the intent and then, you can communicate with it. JCD: Web Intents also provides some isolation between the client and the service. Are you providing this isolation too ? If your APP A and B can later establish a communication channel, it seems not. Yet that is a very appealing feature. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [DOM4] Mutation algorithm imposed order on document children
Okay, I'll use that one. Both the editors draft and the referenced one are same in this respect though. On Tue, Jun 12, 2012 at 5:15 AM, Arthur Barstow art.bars...@nokia.comwrote: Elliott, All - please use the www-...@w3.org list for DOM4 discussions http://lists.w3.org/Archives/**Public/www-dom/http://lists.w3.org/Archives/Public/www-dom/ . (Elliott, since that spec is still in the draft phase, you should probably use the latest Editor's Draft http://dvcs.w3.org/hg/** domcore/raw-file/tip/Overview.**htmlhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html instead of the version in w3.org/TR/)
Re: [DOM4] Mutation algorithm imposed order on document children
On Mon, Jun 11, 2012 at 9:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/12 7:39 PM, Elliott Sprehn wrote:
After discussing this with some other contributors there were questions
on why we're enforcing the order of the document child nodes.
Because otherwise serialization of the result would be ... very broken?
Inserting doctype nodes has no effect on the mode of the document though,
so it's already possible to produce a broken serialization (one in the
wrong mode). For instance you can remove the doctype node and then
serialize or swap the doctype node and then serialize.
Can we leave the behavior when your document is out of order unspecified?
You mean allow UAs to throw or not as they wish? That seems like a pretty
bad idea, honestly. We should require that the insertion be allowed (and
then specify what DOM it produces) or require that it throw.
In practice I don't think anyone inserts these in the wrong order (or
insert doctypes at all since they have no effect). If you wanted to
dynamically create a document you'd do it with document.write('!DOCTYPE
html') and then replaceChild the root element which was created for you.
Implementing this ordering restriction requires changing the append and
replace methods substantially in Webkit for a case I'm not sure developers
realize exists.
- Elliott
Re: [DOM4] Mutation algorithm imposed order on document children
On Tue, Jun 12, 2012 at 10:48 AM, Elliott Sprehn espr...@gmail.com wrote:
On Mon, Jun 11, 2012 at 9:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/12 7:39 PM, Elliott Sprehn wrote:
After discussing this with some other contributors there were questions
on why we're enforcing the order of the document child nodes.
Because otherwise serialization of the result would be ... very broken?
Inserting doctype nodes has no effect on the mode of the document though,
so it's already possible to produce a broken serialization (one in the
wrong mode). For instance you can remove the doctype node and then
serialize or swap the doctype node and then serialize.
Can we leave the behavior when your document is out of order unspecified?
You mean allow UAs to throw or not as they wish? That seems like a
pretty bad idea, honestly. We should require that the insertion be allowed
(and then specify what DOM it produces) or require that it throw.
We should specify it to be allowed IMO unless there is actually a valid
use-case.
In practice I don't think anyone inserts these in the wrong order (or
insert doctypes at all since they have no effect). If you wanted to
dynamically create a document you'd do it with document.write('!DOCTYPE
html') and then replaceChild the root element which was created for you.
I think you can make a stronger argument. It's extremely rare to create a
doctype and append it to a document at all since it doesn't affect the
compat mode. What's the use-case?
Boris, does appending a doctype to a document change compatMode in gecko in
some cases? I don't know of any effect it has in WebKit.
Implementing this ordering restriction requires changing the append and
replace methods substantially in Webkit for a case I'm not sure developers
realize exists.
- Elliott
www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order on document children
This confusion seems to come up a lot since DOM is part of public-webapps but uses a separate mailing list. Maybe it's time to reconsider that decision? It's the editors of the specs who have the largest say here IMO. Travis, Jacob, Ms2ger, Aryeh, Anne: How would feel about merging DOM discussions back into public-webapps@? Ojan On Tue, Jun 12, 2012 at 5:15 AM, Arthur Barstow art.bars...@nokia.comwrote: Elliott, All - please use the www-...@w3.org list for DOM4 discussions http://lists.w3.org/Archives/**Public/www-dom/http://lists.w3.org/Archives/Public/www-dom/ . (Elliott, since that spec is still in the draft phase, you should probably use the latest Editor's Draft http://dvcs.w3.org/hg/** domcore/raw-file/tip/Overview.**htmlhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html instead of the version in w3.org/TR/) -Thanks, AB Original Message Subject:[DOM4] Mutation algorithm imposed order on document children Resent-Date:Tue, 12 Jun 2012 01:01:51 + Resent-From:public-webapps@w3.org Date: Mon, 11 Jun 2012 16:39:36 -0700 From: ext Elliott Sprehn espr...@gmail.com To: public-webapps@w3.org I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm and one of the bugs is not throwing an exception when a doctype node is inserted after an element in a document (or other permutations of the same situation). https://bugs.webkit.org/show_**bug.cgi?id=88682https://bugs.webkit.org/show_bug.cgi?id=88682 http://www.w3.org/TR/domcore/#**mutation-algorithmshttp://www.w3.org/TR/domcore/#mutation-algorithms After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Specifically since inserting a doctype node doesn't actually change the doctype so this situation is very unlikely (possibly never happens) in the wild. Not implementing this keeps the code simpler for a case that developers likely never see. Can we leave the behavior when your document is out of order unspecified? - Elliott
Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, 12 Jun 2012 14:08:14 +0100, Glenn Maynard gl...@zewt.org wrote: What's the rationale behind the spec saying not to reconnect at all? If the API makes each app individually handle reconnects, then not only does it push more work on web developers, it'll create two problems: apps that attempt reconnects too rapidly, and ones that--as Odin points out--don't reconnect at all because the developer didn't know he had to. Indeed, I was under impression that SSE keeps connection persistent and does not require any error handling logic from authors. I wrongly assumed that SSE enters permanent failed state only when recovery seems is impossible, e.g. 404 error or DNS error due to an authoritative NXDOMAIN response, and not when the error is caused merely by temporary lack of Internet connectivity. Since SSE already recovers from unexpectedly closed connections, I think it should be safe for authors to assume it will always reconnect when possible. IMHO the spec should require UAs to reconnect whenever possible. Having fire and forget API is a very attractive option. Writing and testing error recovery code, activated only in rare cases, is not fun and won't work for the web. Pusher is a popular service that provides what SSE was supposed to do, but over Web Sockets, and their library reconnects automatically: http://pusher.com/docs/client_api_guide/client_connect#connection-states I think that's a good model to follow. -- regards, Kornel Lesiński
RE: www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order on document children
I wouldn't mind. I'm on both lists anyway. Schepers originally saw it as a way of scoping DOM3 Events discussions away from the noise on public-webapps. I'm not sure that's a real big concern anymore. From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai Sent: Tuesday, June 12, 2012 11:10 AM To: Arthur Barstow Cc: espr...@gmail.com; www-dom; public-webapps Subject: www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order on document children This confusion seems to come up a lot since DOM is part of public-webapps but uses a separate mailing list. Maybe it's time to reconsider that decision? It's the editors of the specs who have the largest say here IMO. Travis, Jacob, Ms2ger, Aryeh, Anne: How would feel about merging DOM discussions back into public-webapps@? Ojan On Tue, Jun 12, 2012 at 5:15 AM, Arthur Barstow art.bars...@nokia.commailto:art.bars...@nokia.com wrote: Elliott, All - please use the www-...@w3.orgmailto:www-...@w3.org list for DOM4 discussions http://lists.w3.org/Archives/Public/www-dom/. (Elliott, since that spec is still in the draft phase, you should probably use the latest Editor's Draft http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html instead of the version in w3.org/TR/http://w3.org/TR/) -Thanks, AB Original Message Subject:[DOM4] Mutation algorithm imposed order on document children Resent-Date:Tue, 12 Jun 2012 01:01:51 + Resent-From:public-webapps@w3.orgmailto:public-webapps@w3.org Date: Mon, 11 Jun 2012 16:39:36 -0700 From: ext Elliott Sprehn espr...@gmail.commailto:espr...@gmail.com To: public-webapps@w3.orgmailto:public-webapps@w3.org I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm and one of the bugs is not throwing an exception when a doctype node is inserted after an element in a document (or other permutations of the same situation). https://bugs.webkit.org/show_bug.cgi?id=88682 http://www.w3.org/TR/domcore/#mutation-algorithms After discussing this with some other contributors there were questions on why we're enforcing the order of the document child nodes. Specifically since inserting a doctype node doesn't actually change the doctype so this situation is very unlikely (possibly never happens) in the wild. Not implementing this keeps the code simpler for a case that developers likely never see. Can we leave the behavior when your document is out of order unspecified? - Elliott
[Bug 17449] It is unclear to set type to be lower case in Blob constructor.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17449 Li Yin li@intel.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Li Yin li@intel.com 2012-06-13 05:34:28 UTC --- From Spec: http://dev.w3.org/2006/webapi/FileAPI/#attributes-blob The ASCII-encoded string in lower case representing the media type of the Blob. It explicitly specified the type should be lower case. Mark the bug to be INVALID. -- 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.
