[whatwg] Sending MessagePorts after they have started

[Jonas Sicking]

Alexey Proskuryakov wrote:
> 
> Nov 14, 2008, в 11:31 PM, Jonas Sicking написал(а):
> 
>>> Could you please explain how this scenario is affected by the port 
>>> being started? Messages are queued in closed ports until those are 
>>> started, so I think that it applies word to word to closed ports.
>>
>> Where the messages are queued are an implementation detail. So you can 
>> queue messages in the outgoing port until you get word from the 
>> receiving port that it has been opened. At that point you know where 
>> the receiving port lives and will always live for the rest of its life 
>> and can send all messages directly there.
> 
> 
> That's an interesting idea! But this means that such ports have to 
> remain entangled (in an invisible manner) even after being explicitly 
> told to close. E.g., if portA sends messages, then is closed, and only 
> after that, portB is started. If messages are to be queued at portA, 
> they will need to be sent at this point - tricky!
> 
> I agree that the communication problem is much simpler than GC though - 
> it's just that trying to fix it makes GC even more complicated because 
> of the need to track forwarding objects, "hidden entangled" state etc.

Indeed.

> Nov 14, 2008, в 11:32 PM, Jonas Sicking написал(а):
> 
>> Actually, come to think of it, what is the BaseURI for workers? I.e. 
>> what URI is importScripts and XHR resolved against?
> 
> "The base URL of a URL passed to an API in a worker is the absolute URL 
> given that the worker's location attribute represents. Both the origin 
> and effective script origin of scripts running in workers are the origin 
> of the absolute URL given that the worker's locationattribute represents."

Hmm.. this makes a lot of sense for importScripts, but for XHR you 
probably want the baseURI to be that of the opening page, since it's 
quite likely that the opening page gave you a URI to open and process.

Of course that would be quite confusing (different baseURIs for 
different APIs), as well as impossible for shared workers as they don't 
have a single document as opener.

What we need is an API for resolving relative URIs, that way scripts can 
at least do the resolving manually. We could also add an API for getting 
the baseURI of the document on the other side of a port (should possibly 
live on the message event).

/ Jonas