Re: HTML5 web messaging - postMessage
The postMessage design outlined in the W3C document edited by Ian
Hickson is not good!
The design of the cross document messaging by Ian Hickson (Google,
Inc.) is very bad.
Even the last version is not good either. The design can be sketched
here as follows.
The sender:
var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
The receiver:
window.addEventListener('message', receiver, false);
function receiver(e) {
if (e.origin == 'http://example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.origin);
} else {
alert(e.data);
}
}
}
This design was messed up by pulling origin (a word that some people
put too much attention more than should).
Even worse, it requires o.contentWindow, this is really no
professional sense. Because of this design, if I open two tabs with
the same url http://www.google.com/ they are not able to communicate.
My proposal is discard the o.contentWindow part requirement.
My better proposal
the sender:
window.postMessage(messageObject,targetDomain optional,windowIDs optional);
Either targetDomain or windowIDs should present.
I propose to use ID rather than name (though window can have a name),
since window.name is not required to be unique within the browser.
then the user agent(i.e. the browser, such as firefox) will do the following
var e={source: {href: get the sender's window.location.href,
windowID: unique windowID within this browser
},
target: {domain: targetDomain as the sender requested,
windows: the array of windowID
},
data: JSON.parse(JSON.stringtify(messageObject)),
ts: the timestamp when the post is requested
};
if(windowIDs presents){
postEvent to those windows.
} else {
traverse the list of all windows
for (each window){
if(the domain of the window matches the target domain of the message) {
postEvent(e);
}
}
the receiver
/*
return true to indicate to continue to receive message from this sender
return false to indicate to deny messages from this sender forever
(as long as the browser can remember this)
*/
function receiver(e) {
if (e.source is accepted) {
take the e.data to do whatever as desired.
return true;
}
return false;
}
window.addEventListener('message', receiver, false);
if the receiver wants to respond to the sender
window.postMessage(messageObject,targetDomain optional,windowIDs optional);
targetDomain can be found from e.source.href
windowID can be found from e.source.windowID
messageObject is the message object intended to be sent.
About domain match
the specification of the target domain can be
www.google.com
or google.com this should match *.google.com
or com this should match *.com
or as for all
or https://www.google.com
or http://www.google.com:9876/abc/
For the last case, if a
window.location.href==http://www.google.com:9876/def/;, then they do
not match.
About Security
As long as the receiver check who is the sender which is identified by
the user agent, there is no security issue at all.
About context sharing within the browser
Whether session data should be shared among the different processes of
the same browser. such as cookies. It seems that firefox does not
allow 2 different processes unless use different profile.
Here, one more setting, whether the windowIDs should be unique across
different process. Within the same process among different tabs, they
must be unique. If no more than one process is allowed, then such
setting is not relevant.
Challenge
A bad design waste people's energy time, to promote the better
solution. I am offering a reward for the 1st one who implement my
proposal. If you can do this before march 1st, 2013, I will give you
$10.
jackis...@gmail.com
pdf version
Last update: 2013.01.27 21:30
Re: CfC: publish FPWD of Streams API; deadline February 2
Hi all, Le 27/01/2013 03:23, Arthur Barstow a écrit : Feras would like to publish a First Public Working Draft (FPWD) of Streams API and this is a Call for Consensus (CfC) to do so, using the following ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by February 2 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. Feras - with Chrome(24) it appears the ED is not loading a W3C stylesheet (looks much better with FF 19.0). Perhaps this is related to the hg http/https mentioned yesterday in [1]. Institut Telecom approves the publication as a FPWD. Regards, Cyril -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0149.html -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
RE: HTML5 web messaging - postMessage
Jack,
With all due respect, this feedback is a little late. The spec in question is
now at candidate recommendation, and there are multiple interoperable
implementation in existence. While this is not to say that the spec cannot be
changed at this point, I would anticipate that many participants in the working
group (include myself) would be very hesitant to change their implementations
due to existing web compatibility.
Having said that, I don't believe that the existing design of postMessage is as
bad is you make it sound :-)
-Travis
-Original Message-
From: Jack (Zhan, Hua Ping) [mailto:jackis...@gmail.com]
Sent: Sunday, January 27, 2013 7:04 PM
To: i...@hixie.ch
Cc: public-webapps@w3.org; wha...@whatwg.org
Subject: Re: HTML5 web messaging - postMessage
The postMessage design outlined in the W3C document edited by Ian
Hickson is not good!
The design of the cross document messaging by Ian Hickson (Google,
Inc.) is very bad.
Even the last version is not good either. The design can be sketched
here as follows.
The sender:
var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
The receiver:
window.addEventListener('message', receiver, false);
function receiver(e) {
if (e.origin == 'http://example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.origin);
} else {
alert(e.data);
}
}
}
This design was messed up by pulling origin (a word that some people
put too much attention more than should).
Even worse, it requires o.contentWindow, this is really no
professional sense. Because of this design, if I open two tabs with
the same url http://www.google.com/ they are not able to communicate.
My proposal is discard the o.contentWindow part requirement.
My better proposal
the sender:
window.postMessage(messageObject,targetDomain optional,windowIDs
optional);
Either targetDomain or windowIDs should present.
I propose to use ID rather than name (though window can have a name),
since window.name is not required to be unique within the browser.
then the user agent(i.e. the browser, such as firefox) will do the
following
var e={source: {href: get the sender's window.location.href,
windowID: unique windowID within this browser
},
target: {domain: targetDomain as the sender requested,
windows: the array of windowID
},
data: JSON.parse(JSON.stringtify(messageObject)),
ts: the timestamp when the post is requested
};
if(windowIDs presents){
postEvent to those windows.
} else {
traverse the list of all windows
for (each window){
if(the domain of the window matches the target domain of the message)
{
postEvent(e);
}
}
the receiver
/*
return true to indicate to continue to receive message from this sender
return false to indicate to deny messages from this sender forever
(as long as the browser can remember this)
*/
function receiver(e) {
if (e.source is accepted) {
take the e.data to do whatever as desired.
return true;
}
return false;
}
window.addEventListener('message', receiver, false);
if the receiver wants to respond to the sender
window.postMessage(messageObject,targetDomain optional,windowIDs
optional);
targetDomain can be found from e.source.href
windowID can be found from e.source.windowID
messageObject is the message object intended to be sent.
About domain match
the specification of the target domain can be
www.google.com
or google.com this should match *.google.com
or com this should match *.com
or as for all
or https://www.google.com
or http://www.google.com:9876/abc/
For the last case, if a
window.location.href==http://www.google.com:9876/def/;, then they do
not match.
About Security
As long as the receiver check who is the sender which is identified by
the user agent, there is no security issue at all.
About context sharing within the browser
Whether session data should be shared among the different processes of
the same browser. such as cookies. It seems that firefox does not
allow 2 different processes unless use different profile.
Here, one more setting, whether the windowIDs should be unique across
different process. Within the same process among different tabs, they
must be unique. If no more than one process is allowed, then such
setting is not relevant.
Challenge
A bad design waste people's energy time, to promote the better
solution. I am offering a reward for the 1st one who implement my
proposal. If you can do this before march 1st, 2013, I will give you
$10.
jackis...@gmail.com
pdf version
Last update: 2013.01.27 21:30
Re: HTML5 web messaging - postMessage
Dear Travis, Glad to hear from you. Are you guys do volunteer job for that? or are you get paid for that? If you guys are volunteering there, I have no say about. If you guys do get paid, then please be professional and put things right at the first place. Bad standard wastes internet community's time, energy, and money too. with best regards Jack (Zhan, Hua Ping) +1-647-971-6390 On Mon, Jan 28, 2013 at 11:19 AM, Travis Leithead travis.leith...@microsoft.com wrote: Jack, With all due respect, this feedback is a little late. The spec in question is now at candidate recommendation, and there are multiple interoperable implementation in existence. While this is not to say that the spec cannot be changed at this point, I would anticipate that many participants in the working group (include myself) would be very hesitant to change their implementations due to existing web compatibility. Having said that, I don't believe that the existing design of postMessage is as bad is you make it sound :-) -Travis
Re: HTML5 web messaging - postMessage
Hi Jack. Here we are both profesionals, volunteers and mainly profesionals volunteering. W3C and WhatWG are not companies but only places where anybody can add propositions and discuss them, but here nobody get money (directly) from work here. Me, for example, I'm just an student. I can understand your point of view and necessity of improve the standards, I also had the same problem in other aspects and complained about it when my propositions where discarded although they improved the standard, but the best I can say to you, if you so much need these modifications, you can implement them yourself, build an adaptor over the current status, or the best addapt your idea about what's the current state of the things. Be angry about don't do the things the right way (as supossed to you) it's not the way to go. Less words, more work. 2013/1/28 Jack (Zhan, Hua Ping) jackis...@gmail.com: Dear Travis, Glad to hear from you. Are you guys do volunteer job for that? or are you get paid for that? If you guys are volunteering there, I have no say about. If you guys do get paid, then please be professional and put things right at the first place. Bad standard wastes internet community's time, energy, and money too. with best regards Jack (Zhan, Hua Ping) +1-647-971-6390 On Mon, Jan 28, 2013 at 11:19 AM, Travis Leithead travis.leith...@microsoft.com wrote: Jack, With all due respect, this feedback is a little late. The spec in question is now at candidate recommendation, and there are multiple interoperable implementation in existence. While this is not to say that the spec cannot be changed at this point, I would anticipate that many participants in the working group (include myself) would be very hesitant to change their implementations due to existing web compatibility. Having said that, I don't believe that the existing design of postMessage is as bad is you make it sound :-) -Travis -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: [whatwg] HTML5 web messaging - postMessage
On Mon, Jan 28, 2013 at 11:31 AM, Jack (Zhan, Hua Ping) jackis...@gmail.com wrote: Dear Travis, Glad to hear from you. Are you guys do volunteer job for that? or are you get paid for that? If you guys are volunteering there, I have no say about. If you guys do get paid, then please be professional and put things right at the first place. Bad standard wastes internet community's time, energy, and money too. FYI, coming into a group (two groups, actually), declaring everything bad, and deriding people for implementing features, is not a helpful attitude. If you don't know how to do something, you should ask questions to find out if there's a way to do it--which there is, shared workers--before declaring that existing standards are a waste of time. -- Glenn Maynard
Re: [whatwg] HTML5 web messaging - postMessage
If the government does not do a good job, we can criticize those in position. If volunteers do not do a good job, it's ok. By the way, whatever we do, we should not expect all people to say to us: You did a good job. with best regards Jack (Zhan, Hua Ping) +1-647-971-6390
Re: [whatwg] HTML5 web messaging - postMessage
On Mon, Jan 28, 2013 at 12:23 PM, Jack (Zhan, Hua Ping) jackis...@gmail.com wrote: If the government does not do a good job, we can criticize those in position. Employees of browser vendors are not tax-funded government employees. If volunteers do not do a good job, it's ok. By the way, whatever we do, we should not expect all people to say to us: You did a good job. We should expect people to be civil and professional. Opening a discussion with this is all wrong and you've all done a bad job is not. Please look at shared workers; they're designed to allow communication between windows. If you have questions about how to do this, feel free to ask (on the list). -- Glenn Maynard
Re: [IndexedDB] How to recover data from IndexedDB if the origin domain don't exist anymore?
Another perspective about the problem: what about doing so with SharedIndexedDB in the same way of SharedWorkers? They allow to be accessed using a name, so it would be useful also here... If you need a better use case, I've been last saturday on the FirefoxOS App Days here at Madrid and talking about installed applications, it would make sense to have a way to access and move the low-level database to another application since applications would run offline and also some of them wouldn't require access to internet at all (for example a to-do list would be good to have cloud syncronization, but it's not mandatory). P.D.: yes, AppCache seems to fix my problem about dissapearing domains (I need to test it) but it doesn't go to the heart of the problem... 2013/1/16 pira...@gmail.com pira...@gmail.com: Good point. You are right about the fact if you a server somewhere it's fairly simple just to popula it, but if you don't have it I don't know what would be a good solution. Maybe the problem is that I misconsidered the posibility that databases can be removed at any time? IndexedDB is designed just for remote server cache purposes? I know my use case (although real) it's very extreme related to IndexedDB usage, but maybe others would be in the same situation... Do you think it's better to do a local backup of the database from time to time? Sent from my Android cell phone, please forgive the lack of format on the text, and my fat thumbs :-P El 16/01/2013 13:34, Kyle Huey m...@kylehuey.com escribió: On Tue, Jan 15, 2013 at 3:57 PM, pira...@gmail.com pira...@gmail.com wrote: Ideas? Doubts? Comments? :-) The use case here is not compelling enough for this amount of complexity. IndexedDB is not guaranteed to be persistent so you can't really have a server-less webapp if you want reliability. Once you have server-side state there's no point in jumping through all these hoops if you switch domains, just repopulate the DB from the server. - Kyle -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
