Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
This lack of generality bothers me on an aesthetic level, but I also
think it has the following real problems:
Agreed on all points.
* Add startConversation() to SharedWorker, but rename it connect()
Makes sense - when we had other MessagePort methods mirrored to worker
global scope, this name was natural, but it no longer is now.
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
I think this can be written as (note the different name of
MessageEvent attribute, and the use of this in onmessage):
onconnect = function(e) {
e.messagePort.onmessage = function() {
this.postMessage(pong);
}
}
In general, one extra line of code doesn't look like a huge downside -
this is not something that needs to be done again and again in client
code.
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Is there any benefit in having a different name for this constructor?
If dedicated and shared workers are going to have identical
implementation (notably, if they have exactly the same lifetime), I
don't see any benefit in making them look different.
- WBR, Alexey Proskuryakov
[whatwg] PDF version comments
I had a quick look at the PDF version of the spec... The check for updates box should probably be hidden. Why are the status boxes in the margin hidden? It seems to me that they would be useful also on paper. The acks section shows question marks for 윤석찬 and 黒澤剛志. Cheers, -- Simon Pieters Opera Software
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/4 Alexey Proskuryakov [EMAIL PROTECTED]:
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
I think this can be written as (note the different name of MessageEvent
attribute, and the use of this in onmessage):
onconnect = function(e) {
e.messagePort.onmessage = function() {
this.postMessage(pong);
}
}
Right you are. Thanks for fixing.
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Is there any benefit in having a different name for this constructor? If
dedicated and shared workers are going to have identical implementation
(notably, if they have exactly the same lifetime), I don't see any benefit
in making them look different.
I don't have a strong opinion on this either way.
- a
[whatwg] ---
The X/HTML spec reads too much like a law and leave little or no room for the creative designer minds that eventually need to work with it. Creative designer minds working on rendering engines and DOM properties ? Sorry, but one creative vendor (MS) apparently is enough to throw the web off balance ... and no reasonable sane person wants to repeat that. I think here you may well have said exactly what is wrong with this whole browser-vendors doing standards problem. Who ever said that the standards are here for browsers? Just because browsers need to implement the standards does NOT, I repeat NOT mean they are written for browser vendors. Especially not the HTML standards. (I would sooner agree with you on this point regarding CSS than HTML). HTML is a markup language that is meant to describe how content is to be tagged so it can be retrieved based on markup. This has absolutely nothing, and I mean NOTHING to do with browsers, screenreaders, bots, or even humans as far as I am concerned. It is a sec standard describing the hooks that exist in the real world that have existed and evolved since mankind could write and later publish. Humans, UAs, bots, etc. only need to know about these hooks and either implement them or use them as described. You mention the DOM for example. Good, the DOM is a way of describing how HTML can be implemented in a browser. If you as browser vendors want to describe that and agree upon it amongst yourselves...fine, I would welcome that. But I fail to see why this means you have any right to change HTML itself in the process. If you want a standard that describes how browsers or UAs in general must deal with HTML than write THAT standard, but leave HTML out of it please. Bert
Re: [whatwg] ---
Who ever said that the standards are here for browsers? That's the whoe point of standards: to ensure interoperability between the laters. HTML is a markup language that is meant to describe how content is to be tagged so it can be retrieved based on markup. This has absolutely nothing, and I mean NOTHING to do with browsers, screenreaders, bots, or even humans as far as I am concerned. HTML still needs to be interpreted and rendered. You mention the DOM for example. Good, the DOM is a way of describing how HTML can be implemented in a browser. If you as browser vendors want to describe that and agree upon it amongst yourselves...fine, I would welcome that. That's what the WHATWG and W3C are for: to agree a common set of rules for web technologies. Thanks for the laugh. Now, think twice before rewritting such non-sense. Goodbye.
Re: [whatwg] ---
Who ever said that the standards are here for browsers? That's the whoe point of standards: to ensure interoperability between the laters. HTML is a markup language that is meant to describe how content is to be tagged so it can be retrieved based on markup. This has absolutely nothing, and I mean NOTHING to do with browsers, screenreaders, bots, or even humans as far as I am concerned. HTML still needs to be interpreted and rendered. You mention the DOM for example. Good, the DOM is a way of describing how HTML can be implemented in a browser. If you as browser vendors want to describe that and agree upon it amongst yourselves...fine, I would welcome that. That's what the WHATWG and W3C are for: to agree a common set of rules for web technologies. Thanks for the laugh. Now, think twice before rewritting such non-sense. Goodbye. No need to get personal. Like I said, I fully understand that UAs must have a standard construct to be able to deal with markup. But that does by no means mean that they should have control over the markup itself. this does not mean ofcourse that UA-vendors couldn't do it; anybody could do it for all I care, as long as they do it with the actual purpose of HTML in mind, and defining an HTML based on the premise it must be able to render on our browsers is clearly not it. You have got it the wrong way round, it is our browser can render it that would be correct. Bert
Re: [whatwg] ---
Ok, let's try to get the heat off of this discussion. Let me try to explain it. The HTML spec consists of several parts. Some of these parts are indeed browsers spcific, like the DOM, the rendering engine, etc. But the other part is pure semantics. It is about marking up content. I agree that the first part should be done by UA vendors, but I strongly oppose that the second part is done by them as well. That should be done by linguistics, typographs, and people who have to actually create the content. The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the browser part. I understand, after all that is your job and I am sure you are all very capable of that. But please, let the actual markup language itself be defined by others who are more capable of doing that. Bert
Re: [whatwg] ---
... The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the browser part. I understand, after all that is your job and I am sure you are all very capable of that. But please, let the actual markup language itself be defined by others who are more capable of doing that. Thanks for the laugh, indeed. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] ---
On Nov 4, 2008, at 10:07 AM, Pentasis wrote: Ok, let's try to get the heat off of this discussion. Let me try to explain it. The HTML spec consists of several parts. Some of these parts are indeed browsers spcific, like the DOM, the rendering engine, etc. But the other part is pure semantics. It is about marking up content. I agree that the first part should be done by UA vendors, but I strongly oppose that the second part is done by them as well. That should be done by linguistics, typographs, and people who have to actually create the content. The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the browser part. I understand, after all that is your job and I am sure you are all very capable of that. But please, let the actual markup language itself be defined by others who are more capable of doing that. The HTML5 spec is open to feedback from linguists, typographers and content creators. I would agree we should particularly give consideration to people with those backgrounds with regards to issues of semantics. On the other hand, there is not total freedom here because some choices will result in conflict with Web compatibility or with practical implementation concerns. Do you have any specific concerns about the current spec? That would be more useful than criticizing the design process in the abstract. Regards, Maciej
Re: [whatwg] ---
On Tue, 4 Nov 2008, Pentasis wrote: Who ever said that the standards are here for browsers? The HTML5 spec exists for a number of groups, primarily Web authors (and people writing tutorials for Web authors), Web browser implementors, tool implementors, and validator implementors. Roughly in that order. You mention the DOM for example. Good, the DOM is a way of describing how HTML can be implemented in a browser. If you as browser vendors want to describe that and agree upon it amongst yourselves...fine, I would welcome that. But I fail to see why this means you have any right to change HTML itself in the process. We don't really have a right to write HTML anymore than anyone else, but in our version of HTML, we're making sure that the rules for browsers are defined along with the rules for Web authors. It's part of our effort. Making sure the DOM aspects of this are well-defined is a key part of this process, so we have phrased HTML5 such that it is actually defined in terms of the DOM. If you want a standard that describes how browsers or UAs in general must deal with HTML than write THAT standard, but leave HTML out of it please. HTML5 is, amongst other things, that standard. On Tue, 4 Nov 2008, Pentasis wrote: Like I said, I fully understand that UAs must have a standard construct to be able to deal with markup. But that does by no means mean that they should have control over the markup itself. Indeed, browser vendors are just one of many groups of people who are involved in this effort. On Tue, 4 Nov 2008, Pentasis wrote: The HTML spec consists of several parts. Some of these parts are indeed browsers spcific, like the DOM, the rendering engine, etc. But the other part is pure semantics. It is about marking up content. I agree that the first part should be done by UA vendors, but I strongly oppose that the second part is done by them as well. That should be done by linguistics, typographs, and people who have to actually create the content. Input from everyone is welcome. The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the browser part. I understand, after all that is your job and I am sure you are all very capable of that. HTML5's emphasis appears to be on the browser part only because that part is more complex than other parts. (I can't speak for the other specs, though I wouldn't say that they are really browser-emphasised.) But please, let the actual markup language itself be defined by others who are more capable of doing that. We welcome input from everyone. Incidentally, I'd like to remind everyone that conversations on this list have to remain civil and everyone should be treated with respect, regardless of their opinions. If people are rude, I will take action. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Note that I do not think it is necessary to implement this all at
once. For one, the SharedWorker constructor could easily be punted for
future releases.
Thoughts?
My main concern is that I think this makes the most simple use case a
bit too complicated. In the case when you have a dedicated worker that
you want to offload some calculations too you need quite a bit of code
to set up that communication.
With the current API you'd do the following:
main.js:
w = new Worker('worker.js');
w.postMessage(17);
w.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onmessage = function(e) {
postMessage(heavyCalculation(e.data));
}
With the proposed API:
main.js:
w = new Worker('worker.js');
p = w.connect();
p.postMessage(17);
p.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onconnect = function(e) {
e.port.onmessage = function(e2) {
e.port.postMessage(heavyCalulation(e2.data));
}
}
This complexity I feel is extra bad since I suspect the simple case is
going to be the common case (I know we disagree there). I especially
dislike the fact that you have to wait for two events, first a 'connect'
event and then the actual message event. This seems overly complex for
the simple case of simply wanting to use a single communication channel
with a dedicated worker. And even though there isn't that much more code
in my example above, it took significantly more effort to get it right
given the nested two handlers that were needed.
So I think we should keep the simple case of a dedicated worker and a
single communication channel as simple as possible. This means that I
think we should keep postMessage/onmessage available on the dedicated
worker directly, as well as the dedicated worker global scope.
As an added bonus this keeps things very similar to message passing
between windows.
I'm fine with removing things like 'startConversation' and the implicit
call to connect() on shared workers. 'startConversation' isn't really a
new communication mechanism, but rather a convenience method on top of
postMessage.
/ Jonas
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Jonas Sicking wrote:
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage(pong);
}
}
Shared workers are exactly the same except the constructor is
SharedWorker(foo.js, foo);
Note that I do not think it is necessary to implement this all at
once. For one, the SharedWorker constructor could easily be punted for
future releases.
Thoughts?
My main concern is that I think this makes the most simple use case a
bit too complicated. In the case when you have a dedicated worker that
you want to offload some calculations too you need quite a bit of code
to set up that communication.
With the current API you'd do the following:
main.js:
w = new Worker('worker.js');
w.postMessage(17);
w.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onmessage = function(e) {
postMessage(heavyCalculation(e.data));
}
With the proposed API:
main.js:
w = new Worker('worker.js');
p = w.connect();
p.postMessage(17);
p.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onconnect = function(e) {
e.port.onmessage = function(e2) {
e.port.postMessage(heavyCalulation(e2.data));
}
}
This complexity I feel is extra bad since I suspect the simple case is
going to be the common case (I know we disagree there). I especially
dislike the fact that you have to wait for two events, first a 'connect'
event and then the actual message event. This seems overly complex for
the simple case of simply wanting to use a single communication channel
with a dedicated worker. And even though there isn't that much more code
in my example above, it took significantly more effort to get it right
given the nested two handlers that were needed.
So I think we should keep the simple case of a dedicated worker and a
single communication channel as simple as possible. This means that I
think we should keep postMessage/onmessage available on the dedicated
worker directly, as well as the dedicated worker global scope.
As an added bonus this keeps things very similar to message passing
between windows.
I'm fine with removing things like 'startConversation' and the implicit
call to connect() on shared workers. 'startConversation' isn't really a
new communication mechanism, but rather a convenience method on top of
postMessage.
So Hixie brought up a good point on IRC, there really is only one
communication mechanism, which is postMessage/onmessage.
I'd note that if we drop startConversation (which it seems like no-one
is opposing) then all proposals have two 'communication' mechanisms:
postMessage and connect.
With Aarons proposal you have to both for a shared worker and a
dedicated worker use both mechanisms; first call connect() and then call
postMessage(). If keep postMessage on the dedicated worker the only
difference is that for a dedicated worker you skip the connect() and go
directly to postMessage.
/ Jonas
Re: [whatwg] ---
Pentasis wrote: Who ever said that the standards are here for browsers? Tim Berners-Lee apparently when he introduced a bunch of technologies such as HTTP, HTML FTP, IP TCIP and others and called it the World Wide Web, closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox ;-) [http://en.wikipedia.org/wiki/Mosaic_(web_browser)] -- Martin McEvoy http://weborganics.co.uk/
Re: [whatwg] ---
2008/11/5 Martin McEvoy [EMAIL PROTECTED]: [...] closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox Ancestor, surely?
Re: [whatwg] ---
On Wed, Nov 5, 2008 at 2:42 AM, Martin McEvoy [EMAIL PROTECTED] wrote: Tim Berners-Lee apparently when he introduced a bunch of technologies such as HTTP, HTML FTP, IP TCIP and others and called it the World Wide Web, closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox ;-) [http://en.wikipedia.org/wiki/Mosaic_(web_browser)] Netscape got the engineering team which made mosaic, hence Mozilla (mosaic killer). But the engine actually is more directly related to Internet Explorer. http://en.wikipedia.org/wiki/Internet_Explorer#History
