Nov 14, 2008, в 3:59 AM, Ian Hickson написал(а):
For the sake of completeness, a connect/startConversation method on a
worker really should automatically open the receiving port - this is
what examples posted so far implied, and it would cause a lot of
aggravation if it didn't. I know I'm
Nov 14, 2008, в 7:37 AM, Jonas Sicking написал(а):
Feel free to try our implementation of a subset of the spec ;)
I did not say that there was anything wrong with Mozilla's
implementation! What I said was that it was very different from the
current spec, at least in spirit.
In fact,
Alexey Proskuryakov wrote:
Nov 6, 2008, в 2:18 AM, Jonas Sicking написал(а):
Similarly, having separate interfaces for Worker and SharedWorker
implies that there is some fundamental difference in their behavior -
a difference that eludes me so far.
A shared worker is shared between all
2008/11/13 Jonas Sicking [EMAIL PROTECTED]:
So at this point the main problem with making any changes is that we
are very close to shipping Firefox 3.1. I.e. it is extremely hard to
make changes. It is very unfortunate that we have ended up in this
situation again. We were in a very similar to
Here are my preference on changes, in descending order:
* Add a connect() method to Worker and/or SharedWorker
There has been lots of talk about this, but I'm still confused as to
what the exact proposals are due to lack of details. But here is my
interpretation
Details:
- Make instantiating a
Nov 14, 2008, в 1:20 AM, Jonas Sicking написал(а):
If we don't make the above change, I think that we should remove
startConversation(). It doesn't offer enough different functionality
over passing a |new MessageChannel().port2| to be worth the extra API
IMO.
No, this is *exactly* the same
On Thu, 13 Nov 2008, Alexey Proskuryakov wrote:
I like that it doesn't tie Worker and MessagePort lifetimes too closely,
which means that it has a higher chance of being paradox-free.
Could you elaborate on this? I'm not sure I understand. What paradoxes
might exist?
On Thu, 13 Nov 2008,
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Honestly I'm not really sure why the spec says that you need a list at
all, other than maybe to talk about GC (which i've many times mentioned
I think the spec should not need to define).
I remembered what it was that I was trying to remember the
Ian Hickson wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Honestly I'm not really sure why the spec says that you need a list at
all, other than maybe to talk about GC (which i've many times mentioned
I think the spec should not need to define).
I remembered what it was that I was trying
On Thu, 13 Nov 2008, Jonas Sicking wrote:
I don't really see how we can do away with this without interop
issues.
It sounds to me like simply saying:
setTimout(handler, ms):
When called will schedule a event 'ms' milliseconds after the function
is called. When the event fires
Ian Hickson wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
I don't really see how we can do away with this without interop
issues.
It sounds to me like simply saying:
setTimout(handler, ms):
When called will schedule a event 'ms' milliseconds after the function
is called. When the event
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
* Add startConversation() to SharedWorker, but rename it connect()
and make the onconnect event fire inside the worker each time it is
called.
What event do you suggest to dispatch in the worker when connect() is
called? From the above,
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
* Add startConversation() to SharedWorker, but rename it connect()
and make the onconnect event fire inside the worker each time it is
called.
What event do you suggest to dispatch in the
Nov 12, 2008, в 9:26 PM, Aaron Boodman написал(а):
* Add startConversation() to SharedWorker, but rename it connect()
and make the onconnect event fire inside the worker each time it is
called.
What event do you suggest to dispatch in the worker when connect() is
called?
I meant connect.
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
Well, that's what MessagePort.startConversation() sends, and the proposal
only said that connect() is a renamed startConversation() from Worker (also,
The postMessage() and startConversation() methods on Worker objects must
act as if, when
Nov 13, 2008, в 1:34 AM, Aaron Boodman написал(а):
It doesn't make sense to me that startConversation() would dispatch a
MessageEvent object with name message. If that's what the spec
currently says, I think it should be changed.
The startConversation(message) method is a convenience method
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
The startConversation(message) method is a convenience method that
simplifies create a new MessageChannel and invokingpostMessage() with one of
the new ports. - it doesn't do anything postMessage() couldn't do.
Receivers are supposed to
Nov 13, 2008, в 1:46 AM, Aaron Boodman написал(а):
I feel that it probably is not productive to continue discussing
details when there is disagreement on the large-scale shape of the API
between myself, Jonas, and Hixie.
This is a weird situation indeed, as Firefox seems to be about to ship
On Wed, 12 Nov 2008, Aaron Boodman wrote:
I feel that it probably is not productive to continue discussing details
when there is disagreement on the large-scale shape of the API between
myself, Jonas, and Hixie. My opinion on this detail, for example,
probably varies depending on whether
Nov 13, 2008, в 3:37 AM, Ian Hickson написал(а):
In general I think the startConversation() issue is a red herring. The
method was added just as a convenience and isn't really needed. I can
remove it if it would make the discussions simpler.
As far as I'm concerned, there is no issue any
Nov 5, 2008, в 1:11 AM, Jonas Sicking написал(а):
main.js:
w = new Worker('worker.js');
p = w.connect();
p.postMessage(17);
p.onmessage = function(e) {
answer = e.data;
}
I prefer to think of it as:
window.onload = function() {
var worker = new Worker('encrypt.js');
var workerPort
Jonas, Hixie, and I talked about this yesterday on IRC (logs start
here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
into the next day).
Jonas is still against removing postMessage/onmessage from the Worker
interface in favor of connect() only. Also, several people feel like
Nov 5, 2008, в 11:06 PM, Aaron Boodman написал(а):
Jonas, Hixie, and I talked about this yesterday on IRC (logs start
here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
into the next day).
...
* Remove startConversation() from the Worker interface
* Remove the port property
On Wed, 5 Nov 2008, Aaron Boodman wrote:
In light of both of these, I have a new proposal for how to
simplify/combine these two interfaces. Here are the deltas from the
current spec:
* Remove startConversation() from the Worker interface
And from MessagePort, presumably?
* Remove the
Alexey Proskuryakov wrote:
Nov 5, 2008, в 11:06 PM, Aaron Boodman написал(а):
Jonas, Hixie, and I talked about this yesterday on IRC (logs start
here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
into the next day).
...
* Remove startConversation() from the Worker interface
Ian Hickson wrote:
* Remove the port property from the SharedWorker interface and give it
a postMessage and onmessage just like dedicated workers have.
I really don't like this. With (Dedicated)Worker it makes sense because
both sides bury the underlying message channel and ports and so
Nov 6, 2008, в 2:18 AM, Jonas Sicking написал(а):
Similarly, having separate interfaces for Worker and SharedWorker
implies that there is some fundamental difference in their behavior
- a difference that eludes me so far.
A shared worker is shared between all scripts on a single site[*]
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
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
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) {
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) {
Hello all,
A few months ago, I suggested that we combine the DedicatedWorker and
SharedWorker interfaces
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html),
but we never reached consensus.
Since Mozilla and Apple are both working on implementing this now, I'd
like
On Mon, Nov 3, 2008 at 11:08 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
sendMessage()
I'm sorry, please excuse my mixing the names 'sendMessage' and
'postMessage'. The Gears API is named 'sendMessage' and I keep
accidentally using that.
The name in Web Workers should of course be 'postMessage'
33 matches
Mail list logo
