Use port connection whenever possible

[fregante]

Use port connection whenever possible

[fregante]

Did you have any specific requirements that led you to use a persistent port for this channel or was it because the docs seem to suggest there's only chrome.runtime.connect?

The regular sendMessage works in both devtools.html and devtoolsPanel.html:

I'll likely be implementing this part with the the regular sendMessage API, at least for the beginning.

[twschiller]

Did you have any specific requirements that led you to use a persistent port for this channel or was it because the docs seem to

Originally I did it because I was copypasta'ing docs.

When using normal messaging, can the background page initiate messages to the devtools? (What would the tab/frame be for the target?) In the "actor" model the devtools would need to send a message to the background page on initialization. At that point, it's like the port creation, but without the benefits of having a port

What are the benefits of having a port? 1) Lower latency? 2) Getting an event when the port connection is closed?

Maybe we start with regular message, and then move everything to ports (including content script) where it's supported?

[fregante]

When using normal messaging, can the background page initiate messages to the devtools?

I think not, but as pointed out in #3 maybe this is never needed.

What are the benefits of having a port? 1) Lower latency? 2) Getting an event when the port connection is closed?

I think that's the idea.

Maybe we start with regular message, and then move everything to ports (including content script) where it's supported?

Yes, CS also supports ports. What concerns me though is that ports have a major inconvenience:

• the message handler can't respond just by returning, it has to send a message back

This means:

• the sender can't just await runtime.sendMessage but has to listen to messages and connect them to the original message sent
• errors have to be serialized and deserialized manually (or at least handled manually)

For this reason I think I should find out whether the latency is actually lower enough to justify the complexity.

[twschiller]

What concerns me though is that ports have a major inconvenience:

In my mind, a potential benefit this library is to put an abstraction around that, so clients can get the benefits of the port, while still being able to do it with a standard async call

[fregante]

As later discovered, the port only appears to have lower latency because the connection has to happen beforehand. Regular messages have the same latency after the first message to a context.

See pixiebrix/pixiebrix-extension#1546 (comment)